digitalmars.D.bugs - imports

digitalmars.D.bugs - imports - 2 years later

Ant (20/20) Mar 08 2006 Walter, we still have:

Regan Heath (3/23) Mar 08 2006 If you post the code here someone else might have a go at reducing it.

Ant (51/81) Mar 08 2006 :) !

Ant (3/5) Mar 08 2006 should be "linux 0.148 wait, let me grab 149... yep same with 149"
Regan Heath (13/102) Mar 09 2006 I believe Walter discourages the use of import inside a class and I

Regan Heath (5/120) Mar 09 2006 I tried compiling on windows.. and it compiles with no errors. Odd. I wa...
Ant (5/125) Mar 08 2006 but don't you agree the "discourage" should be banned?
Ant (12/14) Mar 09 2006 I need to make a joke and a note:

Derek Parnell (7/16) Mar 09 2006 Why would one think of importing stuff into a class? I don't get it. Are...

Lars Ivar Igesund (3/21) Mar 09 2006 Because when Ant first wrote DUI, class local imports were a workaround ...

Ant (11/32) Mar 09 2006 yes, and more,

Derek Parnell (17/55) Mar 09 2006 But this is the part I don't get. In my opinion, it does make sense to

Ant (3/9) Mar 11 2006 that did it. thanks.

Ant (5/10) Mar 08 2006 even more interesting now that I removed the std.c.stdio from
=?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= (7/32) Mar 09 2006 I think the problem is that DMD tries to be more intelligent than it

Ant (5/38) Mar 08 2006 I think that a valid hypotheses clearly explained.

bobef (3/30) Mar 09 2006 I had the same problem. Removing std.something from one of the modules

Ant (7/14) Mar 09 2006 I think this is much more important then Walter does.

jcc7 (9/25) Mar 09 2006 I think it's an important issue because I know I've wasted a lot of time...

=?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= (13/44) Mar 09 2006 Ok, this is currently a working workaround - but it isn't a valid

Ant (4/31) Mar 09 2006 please forgive me I was mistaken.

Ant (4/37) Mar 09 2006 anybody has Walter's phone number? I need to call him about this.

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

"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

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

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

"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! :)

  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.

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

"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! :)

  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.

 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

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! :)

  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.

 
 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

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

"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

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

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

"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

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

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

=?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

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

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

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

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

=?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

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

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

D Programming

C/C++ Programming

Other

digitalmars.D.bugs - imports - 2 years later