www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - imports - 2 years later

reply Ant <duitoolkit yahoo.ca> writes:
Walter, we still have:

gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with
gtk.TextChildAnchor.std at 
gtk/TextChildAnchor.d(46)
gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with
gtk.TextChildAnchor.std at 
gtk/TextChildAnchor.d(46)
gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with
gtk.TextChildAnchor.std at 
gtk/TextChildAnchor.d(46)
gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with
gtk.TextChildAnchor.std at 
gtk/TextChildAnchor.d(46)
gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with
gtk.TextChildAnchor.std at 
gtk/TextChildAnchor.d(46)
gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with
gtk.TextChildAnchor.std at 
gtk/TextChildAnchor.d(46)


these are both private import std.string;

the interesting thing is that I had a
private import std.c.stdio;
in one module that would supply std.string to a bunch of other modules

well, I know you cannot do anything about this
and I know I cannot reduce this problem... but it's better than 2 year ago! :)

Ant
Mar 08 2006
next sibling parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Wed, 08 Mar 2006 19:35:22 +0000, Ant <duitoolkit yahoo.ca> wrote:
 Walter, we still have:

 gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with  
 gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)
 gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with  
 gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)
 gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with  
 gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)
 gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with  
 gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)
 gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with  
 gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)
 gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with  
 gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)


 these are both private import std.string;

 the interesting thing is that I had a
 private import std.c.stdio;
 in one module that would supply std.string to a bunch of other modules

 well, I know you cannot do anything about this
 and I know I cannot reduce this problem... but it's better than 2 year  
 ago! :)

If you post the code here someone else might have a go at reducing it. Regan
Mar 08 2006
parent reply Ant <duitoolkit yahoo.ca> writes:
Regan Heath wrote:
 On Wed, 08 Mar 2006 19:35:22 +0000, Ant <duitoolkit yahoo.ca> wrote:
 Walter, we still have:

 gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with 
 gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)
 gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with 
 gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)
 gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with 
 gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)
 gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with 
 gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)
 gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with 
 gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)
 gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with 
 gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)


 these are both private import std.string;

 the interesting thing is that I had a
 private import std.c.stdio;
 in one module that would supply std.string to a bunch of other modules

 well, I know you cannot do anything about this
 and I know I cannot reduce this problem... but it's better than 2 year 
 ago! :)

If you post the code here someone else might have a go at reducing it. Regan

:) ! linux 0.148 wait, let me grad 149... yep some with 149 grab http://svn.dsource.org/projects/dui/trunk/src move the imports in src/gtk/TextBuffer.d to the module level private import std.stdarg; private import std.string; from the src dir compile the duitGtk lib with (change the absolute dirs at the end): dmd gtk/AboutDialog.d gtk/AccelGroup.d gtk/AccelLabel.d gtk/AccelMap.d gtk/Accessible.d gtk/Action.d gtk/ActionGroup.d gtk/Adjustment.d gtk/Alignment.d gtk/Arrow.d gtk/AspectFrame.d gtk/Bin.d gtk/BindingSet.d gtk/Box.d gtk/Button.d gtk/ButtonBox.d gtk/Calendar.d gtk/CellEditable.d gtk/CellLayout.d gtk/CellRenderer.d gtk/CellRendererCombo.d gtk/CellRendererPixbuf.d gtk/CellRendererProgress.d gtk/CellRendererText.d gtk/CellRendererToggle.d gtk/CellView.d gtk/CheckButton.d gtk/CheckMenuItem.d gtk/Clipboard.d gtk/ColorButton.d gtk/ColorSelection.d gtk/ColorSelectionDialog.d gtk/ComboBox.d gtk/ComboBoxEntry.d gtk/Container.d gtk/Curve.d gtk/Dialog.d gtk/DragAndDrop.d gtk/DrawingArea.d gtk/Duit.d gtk/Editable.d gtk/Entry.d gtk/EntryCompletion.d gtk/EventBox.d gtk/Expander.d gtk/FileChooser.d gtk/FileChooserButton.d gtk/FileChooserDialog.d gtk/FileChooserWidget.d gtk/FileFilter.d gtk/FileSelection.d gtk/Fixed.d gtk/FontButton.d gtk/FontSelection.d gtk/FontSelectionDialog.d gtk/Frame.d gtk/GCs.d gtk/GammaCurve.d gtk/HBox.d gtk/HButtonBox.d gtk/HPaned.d gtk/HRuler.d gtk/HScale.d gtk/HScrollbar.d gtk/HSeparator.d gtk/HandleBox.d gtk/IMContext.d gtk/IMContextSimple.d gtk/IMMulticontext.d gtk/IconInfo.d gtk/IconSource.d gtk/IconTheme.d gtk/IconView.d gtk/Idle.d gtk/Image.d gtk/ImageMenuItem.d gtk/InputDialog.d gtk/Invisible.d gtk/Item.d gtk/ItemFactory.d gtk/Label.d gtk/Layout.d gtk/ListStore.d gtk/MainWindow.d gtk/Menu.d gtk/MenuBar.d gtk/MenuItem.d gtk/MenuShell.d gtk/MenuToolButton.d gtk/MessageDialog.d gtk/Misc.d gtk/Notebook.d gtk/ObjectGtk.d gtk/Paned.d gtk/Plug.d gtk/Progress.d gtk/ProgressBar.d gtk/RadioAction.d gtk/RadioButton.d gtk/RadioMenuItem.d gtk/RadioToolButton.d gtk/Range.d gtk/RcStyle.d gtk/Ruler.d gtk/Scale.d gtk/Scrollbar.d gtk/ScrolledWindow.d gtk/Selections.d gtk/Separator.d gtk/SeparatorMenuItem.d gtk/SeparatorToolItem.d gtk/Settings.d gtk/Signals.d gtk/SizeGroup.d gtk/Socket.d gtk/SpinButton.d gtk/StandardEnumerations.d gtk/Statusbar.d gtk/StockItem.d gtk/Style.d gtk/Table.d gtk/TearoffMenuItem.d gtk/TextAttributes.d gtk/TextBuffer.d gtk/TextChildAnchor.d gtk/TextIter.d gtk/TextMark.d gtk/TextTag.d gtk/TextTagTable.d gtk/TextView.d gtk/Timeout.d gtk/ToggleAction.d gtk/ToggleButton.d gtk/ToggleToolButton.d gtk/ToolButton.d gtk/ToolItem.d gtk/Toolbar.d gtk/Tooltips.d gtk/TreeDragSource.d gtk/TreeIter.d gtk/TreeModel.d gtk/TreeModelFilter.d gtk/TreeModelSort.d gtk/TreeNode.d gtk/TreePath.d gtk/TreeRowReference.d gtk/TreeSelection.d gtk/TreeSortable.d gtk/TreeStore.d gtk/TreeView.d gtk/TreeViewColumn.d gtk/Types.d gtk/UIManager.d gtk/VBox.d gtk/VButtonBox.d gtk/VPaned.d gtk/VRuler.d gtk/VScale.d gtk/VScrollbar.d gtk/VSeparator.d gtk/Version.d gtk/Viewport.d gtk/Widget.d gtk/Window.d gtk/WindowGroup.d gtk/typedefs.d lib/Loader.d lib/paths.d lib/gtk.d -I/home/ruimt/devel/D1/Duit/src:/home/ruimt/dmd/src/phobos:/home/ruimt/devel/D1/Duit/src:/home/ uimt/dmd/src/phobos -c -gc -od/home/ruimt/devel/D1/Duit/obj/src -op wc src/*/*.d 165810 715148 5459708 total wc src/gtk/*.d 75926 312346 2279989 total but mostly comments This is a big problem for D that Walter chooses to attribute low priority. Ant
Mar 08 2006
next sibling parent Ant <duitoolkit yahoo.ca> writes:
Ant wrote:
 
 linux 0.148 wait, let me grad 149... yep some with 149

should be "linux 0.148 wait, let me grab 149... yep same with 149" :p
Mar 08 2006
prev sibling parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Wed, 08 Mar 2006 21:39:34 +0000, Ant <duitoolkit yahoo.ca> wrote:
 Regan Heath wrote:
 On Wed, 08 Mar 2006 19:35:22 +0000, Ant <duitoolkit yahoo.ca> wrote:
 Walter, we still have:

 gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with  
 gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)
 gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with  
 gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)
 gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with  
 gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)
 gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with  
 gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)
 gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with  
 gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)
 gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with  
 gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)


 these are both private import std.string;

 the interesting thing is that I had a
 private import std.c.stdio;
 in one module that would supply std.string to a bunch of other modules

 well, I know you cannot do anything about this
 and I know I cannot reduce this problem... but it's better than 2 year  
 ago! :)

Regan

:) ! linux 0.148 wait, let me grad 149... yep some with 149 grab http://svn.dsource.org/projects/dui/trunk/src move the imports in src/gtk/TextBuffer.d to the module level private import std.stdarg; private import std.string; from the src dir compile the duitGtk lib with (change the absolute dirs at the end): dmd gtk/AboutDialog.d gtk/AccelGroup.d gtk/AccelLabel.d gtk/AccelMap.d gtk/Accessible.d gtk/Action.d gtk/ActionGroup.d gtk/Adjustment.d gtk/Alignment.d gtk/Arrow.d gtk/AspectFrame.d gtk/Bin.d gtk/BindingSet.d gtk/Box.d gtk/Button.d gtk/ButtonBox.d gtk/Calendar.d gtk/CellEditable.d gtk/CellLayout.d gtk/CellRenderer.d gtk/CellRendererCombo.d gtk/CellRendererPixbuf.d gtk/CellRendererProgress.d gtk/CellRendererText.d gtk/CellRendererToggle.d gtk/CellView.d gtk/CheckButton.d gtk/CheckMenuItem.d gtk/Clipboard.d gtk/ColorButton.d gtk/ColorSelection.d gtk/ColorSelectionDialog.d gtk/ComboBox.d gtk/ComboBoxEntry.d gtk/Container.d gtk/Curve.d gtk/Dialog.d gtk/DragAndDrop.d gtk/DrawingArea.d gtk/Duit.d gtk/Editable.d gtk/Entry.d gtk/EntryCompletion.d gtk/EventBox.d gtk/Expander.d gtk/FileChooser.d gtk/FileChooserButton.d gtk/FileChooserDialog.d gtk/FileChooserWidget.d gtk/FileFilter.d gtk/FileSelection.d gtk/Fixed.d gtk/FontButton.d gtk/FontSelection.d gtk/FontSelectionDialog.d gtk/Frame.d gtk/GCs.d gtk/GammaCurve.d gtk/HBox.d gtk/HButtonBox.d gtk/HPaned.d gtk/HRuler.d gtk/HScale.d gtk/HScrollbar.d gtk/HSeparator.d gtk/HandleBox.d gtk/IMContext.d gtk/IMContextSimple.d gtk/IMMulticontext.d gtk/IconInfo.d gtk/IconSource.d gtk/IconTheme.d gtk/IconView.d gtk/Idle.d gtk/Image.d gtk/ImageMenuItem.d gtk/InputDialog.d gtk/Invisible.d gtk/Item.d gtk/ItemFactory.d gtk/Label.d gtk/Layout.d gtk/ListStore.d gtk/MainWindow.d gtk/Menu.d gtk/MenuBar.d gtk/MenuItem.d gtk/MenuShell.d gtk/MenuToolButton.d gtk/MessageDialog.d gtk/Misc.d gtk/Notebook.d gtk/ObjectGtk.d gtk/Paned.d gtk/Plug.d gtk/Progress.d gtk/ProgressBar.d gtk/RadioAction.d gtk/RadioButton.d gtk/RadioMenuItem.d gtk/RadioToolButton.d gtk/Range.d gtk/RcStyle.d gtk/Ruler.d gtk/Scale.d gtk/Scrollbar.d gtk/ScrolledWindow.d gtk/Selections.d gtk/Separator.d gtk/SeparatorMenuItem.d gtk/SeparatorToolItem.d gtk/Settings.d gtk/Signals.d gtk/SizeGroup.d gtk/Socket.d gtk/SpinButton.d gtk/StandardEnumerations.d gtk/Statusbar.d gtk/StockItem.d gtk/Style.d gtk/Table.d gtk/TearoffMenuItem.d gtk/TextAttributes.d gtk/TextBuffer.d gtk/TextChildAnchor.d gtk/TextIter.d gtk/TextMark.d gtk/TextTag.d gtk/TextTagTable.d gtk/TextView.d gtk/Timeout.d gtk/ToggleAction.d gtk/ToggleButton.d gtk/ToggleToolButton.d gtk/ToolButton.d gtk/ToolItem.d gtk/Toolbar.d gtk/Tooltips.d gtk/TreeDragSource.d gtk/TreeIter.d gtk/TreeModel.d gtk/TreeModelFilter.d gtk/TreeModelSort.d gtk/TreeNode.d gtk/TreePath.d gtk/TreeRowReference.d gtk/TreeSelection.d gtk/TreeSortable.d gtk/TreeStore.d gtk/TreeView.d gtk/TreeViewColumn.d gtk/Types.d gtk/UIManager.d gtk/VBox.d gtk/VButtonBox.d gtk/VPaned.d gtk/VRuler.d gtk/VScale.d gtk/VScrollbar.d gtk/VSeparator.d gtk/Version.d gtk/Viewport.d gtk/Widget.d gtk/Window.d gtk/WindowGroup.d gtk/typedefs.d lib/Loader.d lib/paths.d lib/gtk.d -I/home/ruimt/devel/D1/Duit/src:/home/ruimt/dmd/src/phobos:/home/ruimt/devel/D1/Duit/src:/home/ uimt/dmd/src/phobos -c -gc -od/home/ruimt/devel/D1/Duit/obj/src -op wc src/*/*.d 165810 715148 5459708 total wc src/gtk/*.d 75926 312346 2279989 total but mostly comments This is a big problem for D that Walter chooses to attribute low priority.

I believe Walter discourages the use of import inside a class and I believe your use of them is the reason for the problem. For example, if you move all the imports within these 3 files to the module level: gobject/ObjectG.d gtk/TextBuffer.d gtk/TextChildAnchor.d the errors vanish.. of course it results in different errors, most of which can be resolved by adding: private import std.string; to the files which use std.string.toString. Regan
Mar 09 2006
next sibling parent "Regan Heath" <regan netwin.co.nz> writes:
On Thu, 09 Mar 2006 22:25:49 +1300, Regan Heath <regan netwin.co.nz> wrote:
 On Wed, 08 Mar 2006 21:39:34 +0000, Ant <duitoolkit yahoo.ca> wrote:
 Regan Heath wrote:
 On Wed, 08 Mar 2006 19:35:22 +0000, Ant <duitoolkit yahoo.ca> wrote:
 Walter, we still have:

 gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with  
 gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)
 gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with  
 gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)
 gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with  
 gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)
 gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with  
 gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)
 gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with  
 gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)
 gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with  
 gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)


 these are both private import std.string;

 the interesting thing is that I had a
 private import std.c.stdio;
 in one module that would supply std.string to a bunch of other modules

 well, I know you cannot do anything about this
 and I know I cannot reduce this problem... but it's better than 2  
 year ago! :)

Regan

:) ! linux 0.148 wait, let me grad 149... yep some with 149 grab http://svn.dsource.org/projects/dui/trunk/src move the imports in src/gtk/TextBuffer.d to the module level private import std.stdarg; private import std.string; from the src dir compile the duitGtk lib with (change the absolute dirs at the end): dmd gtk/AboutDialog.d gtk/AccelGroup.d gtk/AccelLabel.d gtk/AccelMap.d gtk/Accessible.d gtk/Action.d gtk/ActionGroup.d gtk/Adjustment.d gtk/Alignment.d gtk/Arrow.d gtk/AspectFrame.d gtk/Bin.d gtk/BindingSet.d gtk/Box.d gtk/Button.d gtk/ButtonBox.d gtk/Calendar.d gtk/CellEditable.d gtk/CellLayout.d gtk/CellRenderer.d gtk/CellRendererCombo.d gtk/CellRendererPixbuf.d gtk/CellRendererProgress.d gtk/CellRendererText.d gtk/CellRendererToggle.d gtk/CellView.d gtk/CheckButton.d gtk/CheckMenuItem.d gtk/Clipboard.d gtk/ColorButton.d gtk/ColorSelection.d gtk/ColorSelectionDialog.d gtk/ComboBox.d gtk/ComboBoxEntry.d gtk/Container.d gtk/Curve.d gtk/Dialog.d gtk/DragAndDrop.d gtk/DrawingArea.d gtk/Duit.d gtk/Editable.d gtk/Entry.d gtk/EntryCompletion.d gtk/EventBox.d gtk/Expander.d gtk/FileChooser.d gtk/FileChooserButton.d gtk/FileChooserDialog.d gtk/FileChooserWidget.d gtk/FileFilter.d gtk/FileSelection.d gtk/Fixed.d gtk/FontButton.d gtk/FontSelection.d gtk/FontSelectionDialog.d gtk/Frame.d gtk/GCs.d gtk/GammaCurve.d gtk/HBox.d gtk/HButtonBox.d gtk/HPaned.d gtk/HRuler.d gtk/HScale.d gtk/HScrollbar.d gtk/HSeparator.d gtk/HandleBox.d gtk/IMContext.d gtk/IMContextSimple.d gtk/IMMulticontext.d gtk/IconInfo.d gtk/IconSource.d gtk/IconTheme.d gtk/IconView.d gtk/Idle.d gtk/Image.d gtk/ImageMenuItem.d gtk/InputDialog.d gtk/Invisible.d gtk/Item.d gtk/ItemFactory.d gtk/Label.d gtk/Layout.d gtk/ListStore.d gtk/MainWindow.d gtk/Menu.d gtk/MenuBar.d gtk/MenuItem.d gtk/MenuShell.d gtk/MenuToolButton.d gtk/MessageDialog.d gtk/Misc.d gtk/Notebook.d gtk/ObjectGtk.d gtk/Paned.d gtk/Plug.d gtk/Progress.d gtk/ProgressBar.d gtk/RadioAction.d gtk/RadioButton.d gtk/RadioMenuItem.d gtk/RadioToolButton.d gtk/Range.d gtk/RcStyle.d gtk/Ruler.d gtk/Scale.d gtk/Scrollbar.d gtk/ScrolledWindow.d gtk/Selections.d gtk/Separator.d gtk/SeparatorMenuItem.d gtk/SeparatorToolItem.d gtk/Settings.d gtk/Signals.d gtk/SizeGroup.d gtk/Socket.d gtk/SpinButton.d gtk/StandardEnumerations.d gtk/Statusbar.d gtk/StockItem.d gtk/Style.d gtk/Table.d gtk/TearoffMenuItem.d gtk/TextAttributes.d gtk/TextBuffer.d gtk/TextChildAnchor.d gtk/TextIter.d gtk/TextMark.d gtk/TextTag.d gtk/TextTagTable.d gtk/TextView.d gtk/Timeout.d gtk/ToggleAction.d gtk/ToggleButton.d gtk/ToggleToolButton.d gtk/ToolButton.d gtk/ToolItem.d gtk/Toolbar.d gtk/Tooltips.d gtk/TreeDragSource.d gtk/TreeIter.d gtk/TreeModel.d gtk/TreeModelFilter.d gtk/TreeModelSort.d gtk/TreeNode.d gtk/TreePath.d gtk/TreeRowReference.d gtk/TreeSelection.d gtk/TreeSortable.d gtk/TreeStore.d gtk/TreeView.d gtk/TreeViewColumn.d gtk/Types.d gtk/UIManager.d gtk/VBox.d gtk/VButtonBox.d gtk/VPaned.d gtk/VRuler.d gtk/VScale.d gtk/VScrollbar.d gtk/VSeparator.d gtk/Version.d gtk/Viewport.d gtk/Widget.d gtk/Window.d gtk/WindowGroup.d gtk/typedefs.d lib/Loader.d lib/paths.d lib/gtk.d -I/home/ruimt/devel/D1/Duit/src:/home/ruimt/dmd/src/phobos:/home/ruimt/devel/D1/Duit/src:/home/ uimt/dmd/src/phobos -c -gc -od/home/ruimt/devel/D1/Duit/obj/src -op wc src/*/*.d 165810 715148 5459708 total wc src/gtk/*.d 75926 312346 2279989 total but mostly comments This is a big problem for D that Walter chooses to attribute low priority.

I believe Walter discourages the use of import inside a class and I believe your use of them is the reason for the problem. For example, if you move all the imports within these 3 files to the module level: gobject/ObjectG.d gtk/TextBuffer.d gtk/TextChildAnchor.d the errors vanish.. of course it results in different errors, most of which can be resolved by adding: private import std.string; to the files which use std.string.toString.

I tried compiling on windows.. and it compiles with no errors. Odd. I was hoping to get the same error on windows so I could produce a minimal test case. Sorry I can't be of more help. Regan
Mar 09 2006
prev sibling next sibling parent Ant <duitoolkit yahoo.ca> writes:
Regan Heath wrote:
 On Wed, 08 Mar 2006 21:39:34 +0000, Ant <duitoolkit yahoo.ca> wrote:
 Regan Heath wrote:
 On Wed, 08 Mar 2006 19:35:22 +0000, Ant <duitoolkit yahoo.ca> wrote:
 Walter, we still have:

 gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with 
 gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)
 gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with 
 gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)
 gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with 
 gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)
 gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with 
 gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)
 gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with 
 gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)
 gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with 
 gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)


 these are both private import std.string;

 the interesting thing is that I had a
 private import std.c.stdio;
 in one module that would supply std.string to a bunch of other modules

 well, I know you cannot do anything about this
 and I know I cannot reduce this problem... but it's better than 2 
 year ago! :)

Regan

:) ! linux 0.148 wait, let me grad 149... yep some with 149 grab http://svn.dsource.org/projects/dui/trunk/src move the imports in src/gtk/TextBuffer.d to the module level private import std.stdarg; private import std.string; from the src dir compile the duitGtk lib with (change the absolute dirs at the end): dmd gtk/AboutDialog.d gtk/AccelGroup.d gtk/AccelLabel.d gtk/AccelMap.d gtk/Accessible.d gtk/Action.d gtk/ActionGroup.d gtk/Adjustment.d gtk/Alignment.d gtk/Arrow.d gtk/AspectFrame.d gtk/Bin.d gtk/BindingSet.d gtk/Box.d gtk/Button.d gtk/ButtonBox.d gtk/Calendar.d gtk/CellEditable.d gtk/CellLayout.d gtk/CellRenderer.d gtk/CellRendererCombo.d gtk/CellRendererPixbuf.d gtk/CellRendererProgress.d gtk/CellRendererText.d gtk/CellRendererToggle.d gtk/CellView.d gtk/CheckButton.d gtk/CheckMenuItem.d gtk/Clipboard.d gtk/ColorButton.d gtk/ColorSelection.d gtk/ColorSelectionDialog.d gtk/ComboBox.d gtk/ComboBoxEntry.d gtk/Container.d gtk/Curve.d gtk/Dialog.d gtk/DragAndDrop.d gtk/DrawingArea.d gtk/Duit.d gtk/Editable.d gtk/Entry.d gtk/EntryCompletion.d gtk/EventBox.d gtk/Expander.d gtk/FileChooser.d gtk/FileChooserButton.d gtk/FileChooserDialog.d gtk/FileChooserWidget.d gtk/FileFilter.d gtk/FileSelection.d gtk/Fixed.d gtk/FontButton.d gtk/FontSelection.d gtk/FontSelectionDialog.d gtk/Frame.d gtk/GCs.d gtk/GammaCurve.d gtk/HBox.d gtk/HButtonBox.d gtk/HPaned.d gtk/HRuler.d gtk/HScale.d gtk/HScrollbar.d gtk/HSeparator.d gtk/HandleBox.d gtk/IMContext.d gtk/IMContextSimple.d gtk/IMMulticontext.d gtk/IconInfo.d gtk/IconSource.d gtk/IconTheme.d gtk/IconView.d gtk/Idle.d gtk/Image.d gtk/ImageMenuItem.d gtk/InputDialog.d gtk/Invisible.d gtk/Item.d gtk/ItemFactory.d gtk/Label.d gtk/Layout.d gtk/ListStore.d gtk/MainWindow.d gtk/Menu.d gtk/MenuBar.d gtk/MenuItem.d gtk/MenuShell.d gtk/MenuToolButton.d gtk/MessageDialog.d gtk/Misc.d gtk/Notebook.d gtk/ObjectGtk.d gtk/Paned.d gtk/Plug.d gtk/Progress.d gtk/ProgressBar.d gtk/RadioAction.d gtk/RadioButton.d gtk/RadioMenuItem.d gtk/RadioToolButton.d gtk/Range.d gtk/RcStyle.d gtk/Ruler.d gtk/Scale.d gtk/Scrollbar.d gtk/ScrolledWindow.d gtk/Selections.d gtk/Separator.d gtk/SeparatorMenuItem.d gtk/SeparatorToolItem.d gtk/Settings.d gtk/Signals.d gtk/SizeGroup.d gtk/Socket.d gtk/SpinButton.d gtk/StandardEnumerations.d gtk/Statusbar.d gtk/StockItem.d gtk/Style.d gtk/Table.d gtk/TearoffMenuItem.d gtk/TextAttributes.d gtk/TextBuffer.d gtk/TextChildAnchor.d gtk/TextIter.d gtk/TextMark.d gtk/TextTag.d gtk/TextTagTable.d gtk/TextView.d gtk/Timeout.d gtk/ToggleAction.d gtk/ToggleButton.d gtk/ToggleToolButton.d gtk/ToolButton.d gtk/ToolItem.d gtk/Toolbar.d gtk/Tooltips.d gtk/TreeDragSource.d gtk/TreeIter.d gtk/TreeModel.d gtk/TreeModelFilter.d gtk/TreeModelSort.d gtk/TreeNode.d gtk/TreePath.d gtk/TreeRowReference.d gtk/TreeSelection.d gtk/TreeSortable.d gtk/TreeStore.d gtk/TreeView.d gtk/TreeViewColumn.d gtk/Types.d gtk/UIManager.d gtk/VBox.d gtk/VButtonBox.d gtk/VPaned.d gtk/VRuler.d gtk/VScale.d gtk/VScrollbar.d gtk/VSeparator.d gtk/Version.d gtk/Viewport.d gtk/Widget.d gtk/Window.d gtk/WindowGroup.d gtk/typedefs.d lib/Loader.d lib/paths.d lib/gtk.d -I/home/ruimt/devel/D1/Duit/src:/home/ruimt/dmd/src/phobos:/home/ruimt/devel/D1/Duit/src:/home/ uimt/dmd/src/phobos -c -gc -od/home/ruimt/devel/D1/Duit/obj/src -op wc src/*/*.d 165810 715148 5459708 total wc src/gtk/*.d 75926 312346 2279989 total but mostly comments This is a big problem for D that Walter chooses to attribute low priority.

I believe Walter discourages the use of import inside a class and I believe your use of them is the reason for the problem.

but don't you agree the "discourage" should be banned? either is valid or not.
 
 For example, if you move all the imports within these 3 files to the 
 module level:
   gobject/ObjectG.d
   gtk/TextBuffer.d
   gtk/TextChildAnchor.d
 
 the errors vanish.. of course it results in different errors, most of 
 which can be resolved by adding:
   private import std.string;
 
 to the files which use std.string.toString.
 

Thank you! I'll review all my imports. Ant
Mar 08 2006
prev sibling next sibling parent reply Ant <Ant_member pathlink.com> writes:
In article <ops5425bcg23k2f5 nrage.netwin.co.nz>, Regan Heath says...
I believe Walter discourages the use of import inside a class and I  
believe your use of them is the reason for the problem.

I need to make a joke and a note: so we have a ternary logic: - import in module: true - import in function: false - import in class: maybe so we need a new type: the ternarybit or TBit or TimBit for Canadians. (sorry regional joke) and I'm getting better response when I do "angry" posts then with polite posts. I'll keep it up ;) Ant
Mar 09 2006
parent reply "Derek Parnell" <derek psych.ward> writes:
On Fri, 10 Mar 2006 00:28:50 +1100, Ant <Ant_member pathlink.com> wrote:

 In article <ops5425bcg23k2f5 nrage.netwin.co.nz>, Regan Heath says...
 I believe Walter discourages the use of import inside a class and I
 believe your use of them is the reason for the problem.

I need to make a joke and a note: so we have a ternary logic: - import in module: true - import in function: false - import in class: maybe

Why would one think of importing stuff into a class? I don't get it. Are you trying to make the imported stuff 'local' to the class members and nothing else? -- Derek Parnell Melbourne, Australia
Mar 09 2006
parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Derek Parnell wrote:

 On Fri, 10 Mar 2006 00:28:50 +1100, Ant <Ant_member pathlink.com> wrote:
 
 In article <ops5425bcg23k2f5 nrage.netwin.co.nz>, Regan Heath says...
 I believe Walter discourages the use of import inside a class and I
 believe your use of them is the reason for the problem.

I need to make a joke and a note: so we have a ternary logic: - import in module: true - import in function: false - import in class: maybe

Why would one think of importing stuff into a class? I don't get it. Are you trying to make the imported stuff 'local' to the class members and nothing else?

Because when Ant first wrote DUI, class local imports were a workaround to much bigger import problems than those we meet today.
Mar 09 2006
parent reply Ant <Ant_member pathlink.com> writes:
In article <dupl7t$mqk$1 digitaldaemon.com>, Lars Ivar Igesund says...
Derek Parnell wrote:

 On Fri, 10 Mar 2006 00:28:50 +1100, Ant <Ant_member pathlink.com> wrote:
 
 In article <ops5425bcg23k2f5 nrage.netwin.co.nz>, Regan Heath says...
 I believe Walter discourages the use of import inside a class and I
 believe your use of them is the reason for the problem.

I need to make a joke and a note: so we have a ternary logic: - import in module: true - import in function: false - import in class: maybe

Why would one think of importing stuff into a class? I don't get it. Are you trying to make the imported stuff 'local' to the class members and nothing else?

Because when Ant first wrote DUI, class local imports were a workaround to much bigger import problems than those we meet today.

yes, and more, I'm going to use the import symbols inside the class body, what makes no sence is to have the import at the module level - see there is always another way to look at things. and more, If I have multiple classes in the same module maybe it makes sence to import the specific modules to the right class. Anyway, this needs to be reviewd. And import in classes should either be corrected (please) or made illegal(no). Ant
Mar 09 2006
parent "Derek Parnell" <derek psych.ward> writes:
On Fri, 10 Mar 2006 04:40:15 +1100, Ant <Ant_member pathlink.com> wrote:

 In article <dupl7t$mqk$1 digitaldaemon.com>, Lars Ivar Igesund says...
 Derek Parnell wrote:

 On Fri, 10 Mar 2006 00:28:50 +1100, Ant <Ant_member pathlink.com>  
 wrote:

 In article <ops5425bcg23k2f5 nrage.netwin.co.nz>, Regan Heath says...
 I believe Walter discourages the use of import inside a class and I
 believe your use of them is the reason for the problem.

I need to make a joke and a note: so we have a ternary logic: - import in module: true - import in function: false - import in class: maybe

Why would one think of importing stuff into a class? I don't get it. Are you trying to make the imported stuff 'local' to the class members and nothing else?

Because when Ant first wrote DUI, class local imports were a workaround to much bigger import problems than those we meet today.

yes, and more, I'm going to use the import symbols inside the class body, what makes no sence is to have the import at the module level - see there is always another way to look at things. and more, If I have multiple classes in the same module maybe it makes sence to import the specific modules to the right class.

But this is the part I don't get. In my opinion, it does make sense to import at the module level, because in D everything in the same module is accessible. Multiple classes in the same module *means* that they are friends and thus can access each other's internals. So importing at the class level can not restrict access between classes residing in the same module. If you really must have restricted access you must also split the classes into different modules.
 Anyway, this needs to be reviewd.

 And import in classes should either be corrected (please) or made  
 illegal(no).

Yes, this does need reviewing and clarificaton. I imagine that the simplest 'correction' would be to that if an import is found inside an aggregate (class or struct) then just assume it to be at the module level. To improve the access granularity, we would need a new scoping keyword (e.g. 'local') in order to sign those members that are only accessible from within the same class/struct. -- Derek Parnell Melbourne, Australia
Mar 09 2006
prev sibling parent Ant <duitoolkit yahoo.ca> writes:
Regan Heath wrote:
 
 which can be resolved by adding:
   private import std.string;
 
 to the files which use std.string.toString.
 

that did it. thanks. Ant
Mar 11 2006
prev sibling next sibling parent Ant <duitoolkit yahoo.ca> writes:
Ant wrote:
 
 the interesting thing is that I had a
 private import std.c.stdio;
 in one module that would supply std.string to a bunch of other modules
 

even more interesting now that I removed the std.c.stdio from that one module and added the std.string where it was missing my Duit lib is screwed up :( Ant
Mar 08 2006
prev sibling next sibling parent reply =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:
Ant wrote:
 Walter, we still have:
 
 gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with
 gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)
 gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with
 gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)
 gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with
 gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)
 gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with
 gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)
 gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with
 gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)
 gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with
 gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)
 
 
 these are both private import std.string;
 
 the interesting thing is that I had a
 private import std.c.stdio;
 in one module that would supply std.string to a bunch of other modules
 
 well, I know you cannot do anything about this
 and I know I cannot reduce this problem... but it's better than 2 year
 ago! :)

I think the problem is that DMD tries to be more intelligent than it really is. It saves the private symbols in the symbol table too, but is unable to hide them, when a public one should "mask" them. Another problem is that when the same module is imported using two different "routes", DMD is unable to determine, whether these modules are the same ones.
Mar 09 2006
parent Ant <duitoolkit yahoo.ca> writes:
Jari-Matti Mäkelä wrote:
 Ant wrote:
 Walter, we still have:

 gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with
 gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)
 gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with
 gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)
 gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with
 gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)
 gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with
 gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)
 gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with
 gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)
 gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with
 gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)


 these are both private import std.string;

 the interesting thing is that I had a
 private import std.c.stdio;
 in one module that would supply std.string to a bunch of other modules

 well, I know you cannot do anything about this
 and I know I cannot reduce this problem... but it's better than 2 year
 ago! :)

I think the problem is that DMD tries to be more intelligent than it really is. It saves the private symbols in the symbol table too, but is unable to hide them, when a public one should "mask" them. Another problem is that when the same module is imported using two different "routes", DMD is unable to determine, whether these modules are the same ones.

I think that a valid hypotheses clearly explained. But what matters is what Walter will do about it. Thank you, Ant
Mar 08 2006
prev sibling next sibling parent reply bobef <bobef lessequal.com> writes:
I had the same problem. Removing std.something from one of the modules 
where it wasn't used at all fixed the problem...

Ant wrote:
 Walter, we still have:
 
 gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with 
 gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)
 gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with 
 gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)
 gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with 
 gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)
 gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with 
 gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)
 gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with 
 gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)
 gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with 
 gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)
 
 
 these are both private import std.string;
 
 the interesting thing is that I had a
 private import std.c.stdio;
 in one module that would supply std.string to a bunch of other modules
 
 well, I know you cannot do anything about this
 and I know I cannot reduce this problem... but it's better than 2 year 
 ago! :)
 
 Ant

Mar 09 2006
next sibling parent reply Ant <Ant_member pathlink.com> writes:
In article <duphvm$hnm$1 digitaldaemon.com>, bobef says...
I had the same problem. Removing std.something from one of the modules 
where it wasn't used at all fixed the problem...

Ant wrote:
 the interesting thing is that I had a
 private import std.c.stdio;
 in one module that would supply std.string to a bunch of other modules
 


I think this is much more important then Walter does. This will prevent D to be used in any sizeable project that involves more then one coder. Is somebody else adds the wrong import on some module I never saw my code will break :( Ant
Mar 09 2006
parent jcc7 <jcc7_member pathlink.com> writes:
In article <dupjbv$jti$1 digitaldaemon.com>, Ant says...
In article <duphvm$hnm$1 digitaldaemon.com>, bobef says...
I had the same problem. Removing std.something from one of the modules 
where it wasn't used at all fixed the problem...

Ant wrote:
 the interesting thing is that I had a
 private import std.c.stdio;
 in one module that would supply std.string to a bunch of other modules
 


I think this is much more important then Walter does. This will prevent D to be used in any sizeable project that involves more then one coder. Is somebody else adds the wrong import on some module I never saw my code will break :( Ant

I think it's an important issue because I know I've wasted a lot of time dealing with similar import errors, but I don't think that Walter actually needs to change the "rules of importing". More descriptive (i.e. helpful) error messages might be all that is needed. I've posted some suggestions about this in the past, but I don't think Walter has had a chance to work on it yet (assuming he even agrees that situation needs to improve). jcc7
Mar 09 2006
prev sibling parent =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:
bobef wrote:
 I had the same problem. Removing std.something from one of the modules
 where it wasn't used at all fixed the problem...

Ok, this is currently a working workaround - but it isn't a valid solution. Try to create a huge framework with 100+ modules and then draw a module dependency graph on a paper. You'll see that it becomes almost impossible to find out, which module you "should" import to avoid these conflicts. This might not be a problem if you write your code (one module at a time) without any previously generated UML graphs, but in a corporate environment this behavior forces you to test your code every once in a while since it's completely possible that a code generator is used to generate the module&class signatures. Currently D modules don't scale very well here. IMHO that's not a practical solution (Walter - hint, hint <g>).
 
 Ant wrote:
 Walter, we still have:

 gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with
 gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)
 gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with
 gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)
 gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with
 gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)
 gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with
 gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)
 gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with
 gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)
 gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with
 gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)


 these are both private import std.string;

 the interesting thing is that I had a
 private import std.c.stdio;
 in one module that would supply std.string to a bunch of other modules

 well, I know you cannot do anything about this
 and I know I cannot reduce this problem... but it's better than 2 year
 ago! :)

 Ant


Mar 09 2006
prev sibling parent reply Ant <duitoolkit yahoo.ca> writes:
Ant wrote:
 Walter, we still have:
 
 gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with 
 gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)
 gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with 
 gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)
 gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with 
 gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)
 gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with 
 gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)
 gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with 
 gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)
 gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with 
 gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)
 
 
 these are both private import std.string;
 
 the interesting thing is that I had a
 private import std.c.stdio;
 in one module that would supply std.string to a bunch of other modules
 
 well, I know you cannot do anything about this
 and I know I cannot reduce this problem... but it's better than 2 year 
 ago! :)
 
 Ant

please forgive me I was mistaken. this is as bad as 2 years ago. Ant
Mar 09 2006
parent Ant <duitoolkit yahoo.ca> writes:
Ant wrote:
 Ant wrote:
 Walter, we still have:

 gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with 
 gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)
 gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with 
 gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)
 gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with 
 gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)
 gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with 
 gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)
 gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with 
 gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)
 gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with 
 gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)


 these are both private import std.string;

 the interesting thing is that I had a
 private import std.c.stdio;
 in one module that would supply std.string to a bunch of other modules

 well, I know you cannot do anything about this
 and I know I cannot reduce this problem... but it's better than 2 year 
 ago! :)

 Ant

please forgive me I was mistaken. this is as bad as 2 years ago. Ant

anybody has Walter's phone number? I need to call him about this. Thank you, Ant
Mar 09 2006