digitalmars.D.ide - VisualD's Intellisense not workign with gtk
- FoxyBrown (35/35) Jul 07 2017 Hi, I get no intellisense with visual d when using gtk.
- Rainer Schuetze (14/66) Jul 11 2017 AFAICT the completion has problems with public imports in imported
- FoxyBrown (2074/2142) Jul 12 2017 No luck. gtk. does nothing intellisense wise. I have all the
- Rainer Schuetze (14/113) Jul 12 2017 It works for me, but takes a couple of seconds to digest all the gtk
- Johnson Jones (11/54) Aug 03 2017 What do I do with the json file when it is created? Where does it
- Johnson Jones (11/77) Aug 03 2017 I put the files in a dir and told that under the JSON edit box in
- Rainer Schuetze (3/77) Aug 04 2017 Yes, more or less the latter. You can also browse the loaded JSON files
- Johnson Jones (15/74) Aug 05 2017 It seems to be working. I haven't done any thorough testing but
- Rainer Schuetze (9/88) Aug 06 2017 As noted before, the JSON support predates semantic analysis. It doesn't...
- Johnson Jones (210/308) Aug 06 2017 (this is a bit long of a post so take your time(when you have
- Rainer Schuetze (28/40) Aug 06 2017 I think there is some misunderstanding about the interaction between the...
- Johnson Jones (28/73) Aug 06 2017 Yeah, but these locals are variables that haven't changed. It's
- Rainer Schuetze (14/82) Aug 07 2017 Yeah, getting some additional information from JSON files could work,
- Johnson (90/180) Aug 07 2017 Could Dscanner not be used?
- Rainer Schuetze (15/125) Aug 09 2017 Dscanner is more a lint-like tool, not usually used for Intellisense.
- Rainer Schuetze (3/14) Aug 10 2017 I have updated the build scripts and the C to D conversion to also work
- Johnson (72/88) Aug 10 2017 Awesome! I think I got it to build!
- Rainer Schuetze (33/108) Aug 10 2017 Sorry, this is an outdated build batch. tlb2idl is also built by the
Hi, I get no intellisense with visual d when using gtk. I use a file that imports all of gtk, like so: module gtk.All; public import gtk.AboutDialog; ... public import gtk.WindowGroup; then I use import gtk = gtk.All but when using gtk. or gtk.WindowGroup. or somegtkWidget. no intellisense ever appears or it appears with only the basic object elements. This makes it very hard to navigate through gtk as I am unfamiliar with most of the nomenclature. Is there any way to get VisualD to properly show the intellisense for these objects and modules? Even if necessarily having to specify direct inclusion. If I just do gtk.gtk.gtk.gtk.gtk.gtk.gtk.... in an empty d file it goes on and on always listing the same intellisense. Changing things like gtk.gtkd.gtk.gtkd.... doesnt change the results. The intellisense listed is ByRecord, Error, Exception, File, Interface, etc. I do not think they are part of gtk. In any case, it clearly isn't working and there doesn't seem to be any way to correct it. It would be nice if we could precompile intellisense data from a set of modules(e.g., specify that it build an intellisense database from a directory recursively... probably would be faster too). Phobos, gtk, and other libraries generally do not change often enough that it should work well. One of the biggest issues I seem to have with Visual D is intellisense not really working correctly, if it works at all, but this isn't a hard problem, is it?
Jul 07 2017
On 07.07.2017 19:23, FoxyBrown wrote:Hi, I get no intellisense with visual d when using gtk. I use a file that imports all of gtk, like so: module gtk.All; public import gtk.AboutDialog; ... public import gtk.WindowGroup; then I use import gtk = gtk.All but when using gtk. or gtk.WindowGroup. or somegtkWidget. no intellisense ever appears or it appears with only the basic object elements. This makes it very hard to navigate through gtk as I am unfamiliar with most of the nomenclature. Is there any way to get VisualD to properly show the intellisense for these objects and modules? Even if necessarily having to specify direct inclusion. If I just do gtk.gtk.gtk.gtk.gtk.gtk.gtk.... in an empty d file it goes on and on always listing the same intellisense. Changing things like gtk.gtkd.gtk.gtkd.... doesnt change the results. The intellisense listed is ByRecord, Error, Exception, File, Interface, etc. I do not think they are part of gtk.AFAICT the completion has problems with public imports in imported modules: they don't add any symbols. This should be fixed in https://github.com/dlang/visuald/releases/tag/v0.45.0-rc1In any case, it clearly isn't working and there doesn't seem to be any way to correct it. It would be nice if we could precompile intellisense data from a set of modules(e.g., specify that it build an intellisense database from a directory recursively... probably would be faster too). Phobos, gtk, and other libraries generally do not change often enough that it should work well.If you let the compiler generate JSON data for your project (see language options), Visual D can add the contained symbols to the completion lists. You can also add precompiled JSON files (see global options). This doesn't use any scope information, though, so the list can grow enormously. One of the biggest issues I seem to have withVisual D is intellisense not really working correctly, if it works at all, but this isn't a hard problem, is it?You bet it is ;-) It needs to rebuild the compiler front end, just being more friendly regarding error recovery and incremental changes. Visual D uses dparser from the Mono-D project, which still seems the most extensive solution.
Jul 11 2017
On Tuesday, 11 July 2017 at 07:16:33 UTC, Rainer Schuetze wrote:On 07.07.2017 19:23, FoxyBrown wrote:No luck. gtk. does nothing intellisense wise. I have all the check boxes checked under language options/intellisense. In the solution.json file, There is this, which only seems to be import modules and enums, no functions are added, maybe that is the problem? I do not have the gtk files in the solution(they are only imported during compilation), do I need to import them in to the solution for everything to work? ( [ { "name" : "gtk.All", "kind" : "module", "file" : "..\\..\\..\\DLang\\GtkD\\generated\\gtkd\\gtk\\All.d", "members" : [ { "name" : "gtk.AboutDialog", "kind" : "import", "line" : 3, "char" : 15 }, { "name" : "gtk.AccelGroup", "kind" : "import", "line" : 4, "char" : 15 }, { "name" : "gtk.AccelLabel", "kind" : "import", "line" : 5, "char" : 15 }, { "name" : "gtk.AccelMap", "kind" : "import", "line" : 6, "char" : 15 }, { "name" : "gtk.Accessible", "kind" : "import", "line" : 7, "char" : 15 }, { "name" : "gtk.Action", "kind" : "import", "line" : 8, "char" : 15 }, { "name" : "gtk.ActionableIF", "kind" : "import", "line" : 9, "char" : 15 }, { "name" : "gtk.ActionableT", "kind" : "import", "line" : 10, "char" : 15 }, { "name" : "gtk.ActionBar", "kind" : "import", "line" : 11, "char" : 15 }, { "name" : "gtk.ActionGroup", "kind" : "import", "line" : 12, "char" : 15 }, { "name" : "gtk.ActivatableIF", "kind" : "import", "line" : 13, "char" : 15 }, { "name" : "gtk.ActivatableT", "kind" : "import", "line" : 14, "char" : 15 }, { "name" : "gtk.Adjustment", "kind" : "import", "line" : 15, "char" : 15 }, { "name" : "gtk.Alignment", "kind" : "import", "line" : 16, "char" : 15 }, { "name" : "gtk.AppChooserButton", "kind" : "import", "line" : 17, "char" : 15 }, { "name" : "gtk.AppChooserDialog", "kind" : "import", "line" : 18, "char" : 15 }, { "name" : "gtk.AppChooserIF", "kind" : "import", "line" : 19, "char" : 15 }, { "name" : "gtk.AppChooserT", "kind" : "import", "line" : 20, "char" : 15 }, { "name" : "gtk.AppChooserWidget", "kind" : "import", "line" : 21, "char" : 15 }, { "name" : "gtk.Application", "kind" : "import", "line" : 22, "char" : 15 }, { "name" : "gtk.ApplicationWindow", "kind" : "import", "line" : 23, "char" : 15 }, { "name" : "gtk.Arrow", "kind" : "import", "line" : 24, "char" : 15 }, { "name" : "gtk.ArrowAccessible", "kind" : "import", "line" : 25, "char" : 15 }, { "name" : "gtk.AspectFrame", "kind" : "import", "line" : 26, "char" : 15 }, { "name" : "gtk.Assistant", "kind" : "import", "line" : 27, "char" : 15 }, { "name" : "gtk.Bin", "kind" : "import", "line" : 28, "char" : 15 }, { "name" : "gtk.BindingEntry", "kind" : "import", "line" : 29, "char" : 15 }, { "name" : "gtk.BindingSet", "kind" : "import", "line" : 30, "char" : 15 }, { "name" : "gtk.BooleanCellAccessible", "kind" : "import", "line" : 31, "char" : 15 }, { "name" : "gtk.Border", "kind" : "import", "line" : 32, "char" : 15 }, { "name" : "gtk.Box", "kind" : "import", "line" : 33, "char" : 15 }, { "name" : "gtk.BuildableIF", "kind" : "import", "line" : 34, "char" : 15 }, { "name" : "gtk.BuildableT", "kind" : "import", "line" : 35, "char" : 15 }, { "name" : "gtk.Builder", "kind" : "import", "line" : 36, "char" : 15 }, { "name" : "gtk.Button", "kind" : "import", "line" : 37, "char" : 15 }, { "name" : "gtk.ButtonAccessible", "kind" : "import", "line" : 38, "char" : 15 }, { "name" : "gtk.ButtonBox", "kind" : "import", "line" : 39, "char" : 15 }, { "name" : "gtk.Calendar", "kind" : "import", "line" : 40, "char" : 15 }, { "name" : "gtk.CellAccessible", "kind" : "import", "line" : 41, "char" : 15 }, { "name" : "gtk.CellAccessibleParentIF", "kind" : "import", "line" : 42, "char" : 15 }, { "name" : "gtk.CellAccessibleParentT", "kind" : "import", "line" : 43, "char" : 15 }, { "name" : "gtk.CellArea", "kind" : "import", "line" : 44, "char" : 15 }, { "name" : "gtk.CellAreaBox", "kind" : "import", "line" : 45, "char" : 15 }, { "name" : "gtk.CellAreaClass", "kind" : "import", "line" : 46, "char" : 15 }, { "name" : "gtk.CellAreaContext", "kind" : "import", "line" : 47, "char" : 15 }, { "name" : "gtk.CellEditable", "kind" : "import", "line" : 48, "char" : 15 }, { "name" : "gtk.CellEditableIF", "kind" : "import", "line" : 49, "char" : 15 }, { "name" : "gtk.CellEditableT", "kind" : "import", "line" : 50, "char" : 15 }, { "name" : "gtk.CellLayoutIF", "kind" : "import", "line" : 51, "char" : 15 }, { "name" : "gtk.CellLayoutT", "kind" : "import", "line" : 52, "char" : 15 }, { "name" : "gtk.CellRenderer", "kind" : "import", "line" : 53, "char" : 15 }, { "name" : "gtk.CellRendererAccel", "kind" : "import", "line" : 54, "char" : 15 }, { "name" : "gtk.CellRendererClass", "kind" : "import", "line" : 55, "char" : 15 }, { "name" : "gtk.CellRendererCombo", "kind" : "import", "line" : 56, "char" : 15 }, { "name" : "gtk.CellRendererPixbuf", "kind" : "import", "line" : 57, "char" : 15 }, { "name" : "gtk.CellRendererProgress", "kind" : "import", "line" : 58, "char" : 15 }, { "name" : "gtk.CellRendererSpin", "kind" : "import", "line" : 59, "char" : 15 }, { "name" : "gtk.CellRendererSpinner", "kind" : "import", "line" : 60, "char" : 15 }, { "name" : "gtk.CellRendererText", "kind" : "import", "line" : 61, "char" : 15 }, { "name" : "gtk.CellRendererToggle", "kind" : "import", "line" : 62, "char" : 15 }, { "name" : "gtk.CellView", "kind" : "import", "line" : 63, "char" : 15 }, { "name" : "gtk.CheckButton", "kind" : "import", "line" : 64, "char" : 15 }, { "name" : "gtk.CheckMenuItem", "kind" : "import", "line" : 65, "char" : 15 }, { "name" : "gtk.CheckMenuItemAccessible", "kind" : "import", "line" : 66, "char" : 15 }, { "name" : "gtk.Clipboard", "kind" : "import", "line" : 67, "char" : 15 }, { "name" : "gtk.ColorButton", "kind" : "import", "line" : 68, "char" : 15 }, { "name" : "gtk.ColorChooserDialog", "kind" : "import", "line" : 69, "char" : 15 }, { "name" : "gtk.ColorChooserIF", "kind" : "import", "line" : 70, "char" : 15 }, { "name" : "gtk.ColorChooserT", "kind" : "import", "line" : 71, "char" : 15 }, { "name" : "gtk.ColorChooserWidget", "kind" : "import", "line" : 72, "char" : 15 }, { "name" : "gtk.ColorSelection", "kind" : "import", "line" : 73, "char" : 15 }, { "name" : "gtk.ColorSelectionDialog", "kind" : "import", "line" : 74, "char" : 15 }, { "name" : "gtk.ComboBox", "kind" : "import", "line" : 75, "char" : 15 }, { "name" : "gtk.ComboBoxAccessible", "kind" : "import", "line" : 76, "char" : 15 }, { "name" : "gtk.ComboBoxText", "kind" : "import", "line" : 77, "char" : 15 }, { "name" : "gtk.Container", "kind" : "import", "line" : 78, "char" : 15 }, { "name" : "gtk.ContainerAccessible", "kind" : "import", "line" : 79, "char" : 15 }, { "name" : "gtk.ContainerCellAccessible", "kind" : "import", "line" : 80, "char" : 15 }, { "name" : "gtk.ContainerClass", "kind" : "import", "line" : 81, "char" : 15 }, { "name" : "gtk.CssProvider", "kind" : "import", "line" : 82, "char" : 15 }, { "name" : "gtk.CssSection", "kind" : "import", "line" : 83, "char" : 15 }, { "name" : "gtk.Dialog", "kind" : "import", "line" : 84, "char" : 15 }, { "name" : "gtk.DragAndDrop", "kind" : "import", "line" : 85, "char" : 15 }, { "name" : "gtk.DrawingArea", "kind" : "import", "line" : 86, "char" : 15 }, { "name" : "gtk.EditableIF", "kind" : "import", "line" : 87, "char" : 15 }, { "name" : "gtk.EditableT", "kind" : "import", "line" : 88, "char" : 15 }, { "name" : "gtk.Entry", "kind" : "import", "line" : 89, "char" : 15 }, { "name" : "gtk.EntryAccessible", "kind" : "import", "line" : 90, "char" : 15 }, { "name" : "gtk.EntryBuffer", "kind" : "import", "line" : 91, "char" : 15 }, { "name" : "gtk.EntryCompletion", "kind" : "import", "line" : 92, "char" : 15 }, { "name" : "gtk.EventBox", "kind" : "import", "line" : 93, "char" : 15 }, { "name" : "gtk.EventController", "kind" : "import", "line" : 94, "char" : 15 }, { "name" : "gtk.Expander", "kind" : "import", "line" : 95, "char" : 15 }, { "name" : "gtk.ExpanderAccessible", "kind" : "import", "line" : 96, "char" : 15 }, { "name" : "gtk.FileChooserButton", "kind" : "import", "line" : 97, "char" : 15 }, { "name" : "gtk.FileChooserDialog", "kind" : "import", "line" : 98, "char" : 15 }, { "name" : "gtk.FileChooserIF", "kind" : "import", "line" : 99, "char" : 15 }, { "name" : "gtk.FileChooserNative", "kind" : "import", "line" : 100, "char" : 15 }, { "name" : "gtk.FileChooserT", "kind" : "import", "line" : 101, "char" : 15 }, { "name" : "gtk.FileChooserWidget", "kind" : "import", "line" : 102, "char" : 15 }, { "name" : "gtk.FileFilter", "kind" : "import", "line" : 103, "char" : 15 }, { "name" : "gtk.Fixed", "kind" : "import", "line" : 104, "char" : 15 }, { "name" : "gtk.FlowBox", "kind" : "import", "line" : 105, "char" : 15 }, { "name" : "gtk.FlowBoxAccessible", "kind" : "import", "line" : 106, "char" : 15 }, { "name" : "gtk.FlowBoxChild", "kind" : "import", "line" : 107, "char" : 15 }, { "name" : "gtk.FlowBoxChildAccessible", "kind" : "import", "line" : 108, "char" : 15 }, { "name" : "gtk.FontButton", "kind" : "import", "line" : 109, "char" : 15 }, { "name" : "gtk.FontChooserDialog", "kind" : "import", "line" : 110, "char" : 15 }, { "name" : "gtk.FontChooserIF", "kind" : "import", "line" : 111, "char" : 15 }, { "name" : "gtk.FontChooserT", "kind" : "import", "line" : 112, "char" : 15 }, { "name" : "gtk.FontChooserWidget", "kind" : "import", "line" : 113, "char" : 15 }, { "name" : "gtk.FontSelection", "kind" : "import", "line" : 114, "char" : 15 }, { "name" : "gtk.FontSelectionDialog", "kind" : "import", "line" : 115, "char" : 15 }, { "name" : "gtk.Frame", "kind" : "import", "line" : 116, "char" : 15 }, { "name" : "gtk.FrameAccessible", "kind" : "import", "line" : 117, "char" : 15 }, { "name" : "gtk.Gesture", "kind" : "import", "line" : 118, "char" : 15 }, { "name" : "gtk.GestureDrag", "kind" : "import", "line" : 119, "char" : 15 }, { "name" : "gtk.GestureLongPress", "kind" : "import", "line" : 120, "char" : 15 }, { "name" : "gtk.GestureMultiPress", "kind" : "import", "line" : 121, "char" : 15 }, { "name" : "gtk.GesturePan", "kind" : "import", "line" : 122, "char" : 15 }, { "name" : "gtk.GestureRotate", "kind" : "import", "line" : 123, "char" : 15 }, { "name" : "gtk.GestureSingle", "kind" : "import", "line" : 124, "char" : 15 }, { "name" : "gtk.GestureSwipe", "kind" : "import", "line" : 125, "char" : 15 }, { "name" : "gtk.GestureZoom", "kind" : "import", "line" : 126, "char" : 15 }, { "name" : "gtk.GLArea", "kind" : "import", "line" : 127, "char" : 15 }, { "name" : "gtk.Gradient", "kind" : "import", "line" : 128, "char" : 15 }, { "name" : "gtk.Grid", "kind" : "import", "line" : 129, "char" : 15 }, { "name" : "gtk.HandleBox", "kind" : "import", "line" : 130, "char" : 15 }, { "name" : "gtk.HBox", "kind" : "import", "line" : 131, "char" : 15 }, { "name" : "gtk.HButtonBox", "kind" : "import", "line" : 132, "char" : 15 }, { "name" : "gtk.HeaderBar", "kind" : "import", "line" : 133, "char" : 15 }, { "name" : "gtk.HPaned", "kind" : "import", "line" : 134, "char" : 15 }, { "name" : "gtk.HScale", "kind" : "import", "line" : 135, "char" : 15 }, { "name" : "gtk.HScrollbar", "kind" : "import", "line" : 136, "char" : 15 }, { "name" : "gtk.HSeparator", "kind" : "import", "line" : 137, "char" : 15 }, { "name" : "gtk.HSV", "kind" : "import", "line" : 138, "char" : 15 }, { "name" : "gtk.IconFactory", "kind" : "import", "line" : 139, "char" : 15 }, { "name" : "gtk.IconInfo", "kind" : "import", "line" : 140, "char" : 15 }, { "name" : "gtk.IconSet", "kind" : "import", "line" : 141, "char" : 15 }, { "name" : "gtk.IconSize", "kind" : "import", "line" : 142, "char" : 15 }, { "name" : "gtk.IconSource", "kind" : "import", "line" : 143, "char" : 15 }, { "name" : "gtk.IconTheme", "kind" : "import", "line" : 144, "char" : 15 }, { "name" : "gtk.IconView", "kind" : "import", "line" : 145, "char" : 15 }, { "name" : "gtk.IconViewAccessible", "kind" : "import", "line" : 146, "char" : 15 }, { "name" : "gtk.Image", "kind" : "import", "line" : 147, "char" : 15 }, { "name" : "gtk.ImageAccessible", "kind" : "import", "line" : 148, "char" : 15 }, { "name" : "gtk.ImageCellAccessible", "kind" : "import", "line" : 149, "char" : 15 }, { "name" : "gtk.ImageMenuItem", "kind" : "import", "line" : 150, "char" : 15 }, { "name" : "gtk.IMContext", "kind" : "import", "line" : 151, "char" : 15 }, { "name" : "gtk.IMContextSimple", "kind" : "import", "line" : 152, "char" : 15 }, { "name" : "gtk.IMMulticontext", "kind" : "import", "line" : 153, "char" : 15 }, { "name" : "gtk.InfoBar", "kind" : "import", "line" : 154, "char" : 15 }, { "name" : "gtk.Invisible", "kind" : "import", "line" : 155, "char" : 15 }, { "name" : "gtk.Label", "kind" : "import", "line" : 156, "char" : 15 }, { "name" : "gtk.LabelAccessible", "kind" : "import", "line" : 157, "char" : 15 }, { "name" : "gtk.Layout", "kind" : "import", "line" : 158, "char" : 15 }, { "name" : "gtk.LevelBar", "kind" : "import", "line" : 159, "char" : 15 }, { "name" : "gtk.LevelBarAccessible", "kind" : "import", "line" : 160, "char" : 15 }, { "name" : "gtk.LinkButton", "kind" : "import", "line" : 161, "char" : 15 }, { "name" : "gtk.LinkButtonAccessible", "kind" : "import", "line" : 162, "char" : 15 }, { "name" : "gtk.ListBox", "kind" : "import", "line" : 163, "char" : 15 }, { "name" : "gtk.ListBoxAccessible", "kind" : "import", "line" : 164, "char" : 15 }, { "name" : "gtk.ListBoxRow", "kind" : "import", "line" : 165, "char" : 15 }, { "name" : "gtk.ListBoxRowAccessible", "kind" : "import", "line" : 166, "char" : 15 }, { "name" : "gtk.ListStore", "kind" : "import", "line" : 167, "char" : 15 }, { "name" : "gtk.LockButton", "kind" : "import", "line" : 168, "char" : 15 }, { "name" : "gtk.LockButtonAccessible", "kind" : "import", "line" : 169, "char" : 15 }, { "name" : "gtk.Main", "kind" : "import", "line" : 170, "char" : 15 }, { "name" : "gtk.MainWindow", "kind" : "import", "line" : 171, "char" : 15 }, { "name" : "gtk.Menu", "kind" : "import", "line" : 172, "char" : 15 }, { "name" : "gtk.MenuAccessible", "kind" : "import", "line" : 173, "char" : 15 }, { "name" : "gtk.MenuBar", "kind" : "import", "line" : 174, "char" : 15 }, { "name" : "gtk.MenuButton", "kind" : "import", "line" : 175, "char" : 15 }, { "name" : "gtk.MenuButtonAccessible", "kind" : "import", "line" : 176, "char" : 15 }, { "name" : "gtk.MenuItem", "kind" : "import", "line" : 177, "char" : 15 }, { "name" : "gtk.MenuItemAccessible", "kind" : "import", "line" : 178, "char" : 15 }, { "name" : "gtk.MenuShell", "kind" : "import", "line" : 179, "char" : 15 }, { "name" : "gtk.MenuShellAccessible", "kind" : "import", "line" : 180, "char" : 15 }, { "name" : "gtk.MenuToolButton", "kind" : "import", "line" : 181, "char" : 15 }, { "name" : "gtk.MessageDialog", "kind" : "import", "line" : 182, "char" : 15 }, { "name" : "gtk.Misc", "kind" : "import", "line" : 183, "char" : 15 }, { "name" : "gtk.ModelButton", "kind" : "import", "line" : 184, "char" : 15 }, { "name" : "gtk.MountOperation", "kind" : "import", "line" : 185, "char" : 15 }, { "name" : "gtk.NativeDialog", "kind" : "import", "line" : 186, "char" : 15 }, { "name" : "gtk.Notebook", "kind" : "import", "line" : 187, "char" : 15 }, { "name" : "gtk.NotebookAccessible", "kind" : "import", "line" : 188, "char" : 15 }, { "name" : "gtk.NotebookPageAccessible", "kind" : "import", "line" : 189, "char" : 15 }, { "name" : "gtk.NumerableIcon", "kind" : "import", "line" : 190, "char" : 15 }, { "name" : "gtk.OffscreenWindow", "kind" : "import", "line" : 191, "char" : 15 }, { "name" : "gtk.OrientableIF", "kind" : "import", "line" : 192, "char" : 15 }, { "name" : "gtk.OrientableT", "kind" : "import", "line" : 193, "char" : 15 }, { "name" : "gtk.Overlay", "kind" : "import", "line" : 194, "char" : 15 }, { "name" : "gtk.PadController", "kind" : "import", "line" : 195, "char" : 15 }, { "name" : "gtk.PageSetup", "kind" : "import", "line" : 196, "char" : 15 }, { "name" : "gtk.Paned", "kind" : "import", "line" : 197, "char" : 15 }, { "name" : "gtk.PanedAccessible", "kind" : "import", "line" : 198, "char" : 15 }, { "name" : "gtk.PaperSize", "kind" : "import", "line" : 199, "char" : 15 }, { "name" : "gtk.PlacesSidebar", "kind" : "import", "line" : 200, "char" : 15 }, { "name" : "gtk.Plug", "kind" : "import", "line" : 201, "char" : 15 }, { "name" : "gtk.Popover", "kind" : "import", "line" : 202, "char" : 15 }, { "name" : "gtk.PopoverAccessible", "kind" : "import", "line" : 203, "char" : 15 }, { "name" : "gtk.PopoverMenu", "kind" : "import", "line" : 204, "char" : 15 }, { "name" : "gtk.PopupBox", "kind" : "import", "line" : 205, "char" : 15 }, { "name" : "gtk.PrintContext", "kind" : "import", "line" : 206, "char" : 15 }, { "name" : "gtk.PrintOperation", "kind" : "import", "line" : 207, "char" : 15 }, { "name" : "gtk.PrintOperationPreview", "kind" : "import", "line" : 208, "char" : 15 }, { "name" : "gtk.PrintOperationPreviewIF", "kind" : "import", "line" : 209, "char" : 15 }, { "name" : "gtk.PrintOperationPreviewT", "kind" : "import", "line" : 210, "char" : 15 }, { "name" : "gtk.PrintSettings", "kind" : "import", "line" : 211, "char" : 15 }, { "name" : "gtk.ProgressBar", "kind" : "import", "line" : 212, "char" : 15 }, { "name" : "gtk.ProgressBarAccessible", "kind" : "import", "line" : 213, "char" : 15 }, { "name" : "gtk.RadioAction", "kind" : "import", "line" : 214, "char" : 15 }, { "name" : "gtk.RadioButton", "kind" : "import", "line" : 215, "char" : 15 }, { "name" : "gtk.RadioButtonAccessible", "kind" : "import", "line" : 216, "char" : 15 }, { "name" : "gtk.RadioMenuItem", "kind" : "import", "line" : 217, "char" : 15 }, { "name" : "gtk.RadioMenuItemAccessible", "kind" : "import", "line" : 218, "char" : 15 }, { "name" : "gtk.RadioToolButton", "kind" : "import", "line" : 219, "char" : 15 }, { "name" : "gtk.Range", "kind" : "import", "line" : 220, "char" : 15 }, { "name" : "gtk.RangeAccessible", "kind" : "import", "line" : 221, "char" : 15 }, { "name" : "gtk.RcProperty", "kind" : "import", "line" : 222, "char" : 15 }, { "name" : "gtk.RcStyle", "kind" : "import", "line" : 223, "char" : 15 }, { "name" : "gtk.RecentAction", "kind" : "import", "line" : 224, "char" : 15 }, { "name" : "gtk.RecentChooserDialog", "kind" : "import", "line" : 225, "char" : 15 }, { "name" : "gtk.RecentChooserIF", "kind" : "import", "line" : 226, "char" : 15 }, { "name" : "gtk.RecentChooserMenu", "kind" : "import", "line" : 227, "char" : 15 }, { "name" : "gtk.RecentChooserT", "kind" : "import", "line" : 228, "char" : 15 }, { "name" : "gtk.RecentChooserWidget", "kind" : "import", "line" : 229, "char" : 15 }, { "name" : "gtk.RecentFilter", "kind" : "import", "line" : 230, "char" : 15 }, { "name" : "gtk.RecentInfo", "kind" : "import", "line" : 231, "char" : 15 }, { "name" : "gtk.RecentManager", "kind" : "import", "line" : 232, "char" : 15 }, { "name" : "gtk.RendererCellAccessible", "kind" : "import", "line" : 233, "char" : 15 }, { "name" : "gtk.Requisition", "kind" : "import", "line" : 234, "char" : 15 }, { "name" : "gtk.Revealer", "kind" : "import", "line" : 235, "char" : 15 }, { "name" : "gtk.Scale", "kind" : "import", "line" : 236, "char" : 15 }, { "name" : "gtk.ScaleAccessible", "kind" : "import", "line" : 237, "char" : 15 }, { "name" : "gtk.ScaleButton", "kind" : "import", "line" : 238, "char" : 15 }, { "name" : "gtk.ScaleButtonAccessible", "kind" : "import", "line" : 239, "char" : 15 }, { "name" : "gtk.ScrollableIF", "kind" : "import", "line" : 240, "char" : 15 }, { "name" : "gtk.ScrollableT", "kind" : "import", "line" : 241, "char" : 15 }, { "name" : "gtk.Scrollbar", "kind" : "import", "line" : 242, "char" : 15 }, { "name" : "gtk.ScrolledWindow", "kind" : "import", "line" : 243, "char" : 15 }, { "name" : "gtk.ScrolledWindowAccessible", "kind" : "import", "line" : 244, "char" : 15 }, { "name" : "gtk.SearchBar", "kind" : "import", "line" : 245, "char" : 15 }, { "name" : "gtk.SearchEntry", "kind" : "import", "line" : 246, "char" : 15 }, { "name" : "gtk.SelectionData", "kind" : "import", "line" : 247, "char" : 15 }, { "name" : "gtk.Separator", "kind" : "import", "line" : 248, "char" : 15 }, { "name" : "gtk.SeparatorMenuItem", "kind" : "import", "line" : 249, "char" : 15 }, { "name" : "gtk.SeparatorToolItem", "kind" : "import", "line" : 250, "char" : 15 }, { "name" : "gtk.Settings", "kind" : "import", "line" : 251, "char" : 15 }, { "name" : "gtk.ShortcutLabel", "kind" : "import", "line" : 252, "char" : 15 }, { "name" : "gtk.ShortcutsGroup", "kind" : "import", "line" : 253, "char" : 15 }, { "name" : "gtk.ShortcutsSection", "kind" : "import", "line" : 254, "char" : 15 }, { "name" : "gtk.ShortcutsShortcut", "kind" : "import", "line" : 255, "char" : 15 }, { "name" : "gtk.ShortcutsWindow", "kind" : "import", "line" : 256, "char" : 15 }, { "name" : "gtk.SizeGroup", "kind" : "import", "line" : 257, "char" : 15 }, { "name" : "gtk.Socket", "kind" : "import", "line" : 258, "char" : 15 }, { "name" : "gtk.SpinButton", "kind" : "import", "line" : 259, "char" : 15 }, { "name" : "gtk.SpinButtonAccessible", "kind" : "import", "line" : 260, "char" : 15 }, { "name" : "gtk.Spinner", "kind" : "import", "line" : 261, "char" : 15 }, { "name" : "gtk.SpinnerAccessible", "kind" : "import", "line" : 262, "char" : 15 }, { "name" : "gtk.Stack", "kind" : "import", "line" : 263, "char" : 15 }, { "name" : "gtk.StackAccessible", "kind" : "import", "line" : 264, "char" : 15 }, { "name" : "gtk.StackSidebar", "kind" : "import", "line" : 265, "char" : 15 }, { "name" : "gtk.StackSwitcher", "kind" : "import", "line" : 266, "char" : 15 }, { "name" : "gtk.Statusbar", "kind" : "import", "line" : 267, "char" : 15 }, { "name" : "gtk.StatusbarAccessible", "kind" : "import", "line" : 268, "char" : 15 }, { "name" : "gtk.StatusIcon", "kind" : "import", "line" : 269, "char" : 15 }, { "name" : "gtk.StockItem", "kind" : "import", "line" : 270, "char" : 15 }, { "name" : "gtk.Style", "kind" : "import", "line" : 271, "char" : 15 }, { "name" : "gtk.StyleContext", "kind" : "import", "line" : 272, "char" : 15 }, { "name" : "gtk.StyleProperties", "kind" : "import", "line" : 273, "char" : 15 }, { "name" : "gtk.StyleProviderIF", "kind" : "import", "line" : 274, "char" : 15 }, { "name" : "gtk.StyleProviderT", "kind" : "import", "line" : 275, "char" : 15 }, { "name" : "gtk.Switch", "kind" : "import", "line" : 276, "char" : 15 }, { "name" : "gtk.SwitchAccessible", "kind" : "import", "line" : 277, "char" : 15 }, { "name" : "gtk.SymbolicColor", "kind" : "import", "line" : 278, "char" : 15 }, { "name" : "gtk.Table", "kind" : "import", "line" : 279, "char" : 15 }, { "name" : "gtk.TargetEntry", "kind" : "import", "line" : 280, "char" : 15 }, { "name" : "gtk.TargetList", "kind" : "import", "line" : 281, "char" : 15 }, { "name" : "gtk.TearoffMenuItem", "kind" : "import", "line" : 282, "char" : 15 }, { "name" : "gtk.Testing", "kind" : "import", "line" : 283, "char" : 15 }, { "name" : "gtk.TextAttributes", "kind" : "import", "line" : 284, "char" : 15 }, { "name" : "gtk.TextBuffer", "kind" : "import", "line" : 285, "char" : 15 }, { "name" : "gtk.TextCellAccessible", "kind" : "import", "line" : 286, "char" : 15 }, { "name" : "gtk.TextChildAnchor", "kind" : "import", "line" : 287, "char" : 15 }, { "name" : "gtk.TextIter", "kind" : "import", "line" : 288, "char" : 15 }, { "name" : "gtk.TextMark", "kind" : "import", "line" : 289, "char" : 15 }, { "name" : "gtk.TextTag", "kind" : "import", "line" : 290, "char" : 15 }, { "name" : "gtk.TextTagTable", "kind" : "import", "line" : 291, "char" : 15 }, { "name" : "gtk.TextView", "kind" : "import", "line" : 292, "char" : 15 }, { "name" : "gtk.TextViewAccessible", "kind" : "import", "line" : 293, "char" : 15 }, { "name" : "gtk.ThemingEngine", "kind" : "import", "line" : 294, "char" : 15 }, { "name" : "gtk.ToggleAction", "kind" : "import", "line" : 295, "char" : 15 }, { "name" : "gtk.ToggleButton", "kind" : "import", "line" : 296, "char" : 15 }, { "name" : "gtk.ToggleButtonAccessible", "kind" : "import", "line" : 297, "char" : 15 }, { "name" : "gtk.ToggleToolButton", "kind" : "import", "line" : 298, "char" : 15 }, { "name" : "gtk.Toolbar", "kind" : "import", "line" : 299, "char" : 15 }, { "name" : "gtk.ToolButton", "kind" : "import", "line" : 300, "char" : 15 }, { "name" : "gtk.ToolItem", "kind" : "import", "line" : 301, "char" : 15 }, { "name" : "gtk.ToolItemGroup", "kind" : "import", "line" : 302, "char" : 15 }, { "name" : "gtk.ToolPalette", "kind" : "import", "line" : 303, "char" : 15 }, { "name" : "gtk.ToolShellIF", "kind" : "import", "line" : 304, "char" : 15 }, { "name" : "gtk.ToolShellT", "kind" : "import", "line" : 305, "char" : 15 }, { "name" : "gtk.Tooltip", "kind" : "import", "line" : 306, "char" : 15 }, { "name" : "gtk.ToplevelAccessible", "kind" : "import", "line" : 307, "char" : 15 }, { "name" : "gtk.TreeDragDestIF", "kind" : "import", "line" : 308, "char" : 15 }, { "name" : "gtk.TreeDragDestT", "kind" : "import", "line" : 309, "char" : 15 }, { "name" : "gtk.TreeDragSourceIF", "kind" : "import", "line" : 310, "char" : 15 }, { "name" : "gtk.TreeDragSourceT", "kind" : "import", "line" : 311, "char" : 15 }, { "name" : "gtk.TreeIter", "kind" : "import", "line" : 312, "char" : 15 }, { "name" : "gtk.TreeIterError", "kind" : "import", "line" : 313, "char" : 15 }, { "name" : "gtk.TreeModel", "kind" : "import", "line" : 314, "char" : 15 }, { "name" : "gtk.TreeModelFilter", "kind" : "import", "line" : 315, "char" : 15 }, { "name" : "gtk.TreeModelIF", "kind" : "import", "line" : 316, "char" : 15 }, { "name" : "gtk.TreeModelSort", "kind" : "import", "line" : 317, "char" : 15 }, { "name" : "gtk.TreeModelT", "kind" : "import", "line" : 318, "char" : 15 }, { "name" : "gtk.TreeNode", "kind" : "import", "line" : 319, "char" : 15 }, { "name" : "gtk.TreePath", "kind" : "import", "line" : 320, "char" : 15 }, { "name" : "gtk.TreeRowReference", "kind" : "import", "line" : 321, "char" : 15 }, { "name" : "gtk.TreeSelection", "kind" : "import", "line" : 322, "char" : 15 }, { "name" : "gtk.TreeSortableIF", "kind" : "import", "line" : 323, "char" : 15 }, { "name" : "gtk.TreeSortableT", "kind" : "import", "line" : 324, "char" : 15 }, { "name" : "gtk.TreeStore", "kind" : "import", "line" : 325, "char" : 15 }, { "name" : "gtk.TreeView", "kind" : "import", "line" : 326, "char" : 15 }, { "name" : "gtk.TreeViewAccessible", "kind" : "import", "line" : 327, "char" : 15 }, { "name" : "gtk.TreeViewColumn", "kind" : "import", "line" : 328, "char" : 15 }, { "name" : "gtk.UIManager", "kind" : "import", "line" : 329, "char" : 15 }, { "name" : "gtk.VBox", "kind" : "import", "line" : 330, "char" : 15 }, { "name" : "gtk.VButtonBox", "kind" : "import", "line" : 331, "char" : 15 }, { "name" : "gtk.Version", "kind" : "import", "line" : 332, "char" : 15 }, { "name" : "gtk.Viewport", "kind" : "import", "line" : 333, "char" : 15 }, { "name" : "gtk.VolumeButton", "kind" : "import", "line" : 334, "char" : 15 }, { "name" : "gtk.VPaned", "kind" : "import", "line" : 335, "char" : 15 }, { "name" : "gtk.VScale", "kind" : "import", "line" : 336, "char" : 15 }, { "name" : "gtk.VScrollbar", "kind" : "import", "line" : 337, "char" : 15 }, { "name" : "gtk.VSeparator", "kind" : "import", "line" : 338, "char" : 15 }, { "name" : "gtk.Widget", "kind" : "import", "line" : 339, "char" : 15 }, { "name" : "gtk.WidgetAccessible", "kind" : "import", "line" : 340, "char" : 15 }, { "name" : "gtk.WidgetClass", "kind" : "import", "line" : 341, "char" : 15 }, { "name" : "gtk.WidgetPath", "kind" : "import", "line" : 342, "char" : 15 }, { "name" : "gtk.Window", "kind" : "import", "line" : 343, "char" : 15 }, { "name" : "gtk.WindowAccessible", "kind" : "import", "line" : 344, "char" : 15 }, { "name" : "gtk.WindowGroup", "kind" : "import", "line" : 345, "char" : 15 } ] },Hi, I get no intellisense with visual d when using gtk. I use a file that imports all of gtk, like so: module gtk.All; public import gtk.AboutDialog; ... public import gtk.WindowGroup; then I use import gtk = gtk.All but when using gtk. or gtk.WindowGroup. or somegtkWidget. no intellisense ever appears or it appears with only the basic object elements. This makes it very hard to navigate through gtk as I am unfamiliar with most of the nomenclature. Is there any way to get VisualD to properly show the intellisense for these objects and modules? Even if necessarily having to specify direct inclusion. If I just do gtk.gtk.gtk.gtk.gtk.gtk.gtk.... in an empty d file it goes on and on always listing the same intellisense. Changing things like gtk.gtkd.gtk.gtkd.... doesnt change the results. The intellisense listed is ByRecord, Error, Exception, File, Interface, etc. I do not think they are part of gtk.AFAICT the completion has problems with public imports in imported modules: they don't add any symbols. This should be fixed in https://github.com/dlang/visuald/releases/tag/v0.45.0-rc1In any case, it clearly isn't working and there doesn't seem to be any way to correct it. It would be nice if we could precompile intellisense data from a set of modules(e.g., specify that it build an intellisense database from a directory recursively... probably would be faster too). Phobos, gtk, and other libraries generally do not change often enough that it should work well.If you let the compiler generate JSON data for your project (see language options), Visual D can add the contained symbols to the completion lists. You can also add precompiled JSON files (see global options). This doesn't use any scope information, though, so the list can grow enormously. One of the biggest issues I seem to have withVisual D is intellisense not really working correctly, if it works at all, but this isn't a hard problem, is it?You bet it is ;-) It needs to rebuild the compiler front end, just being more friendly regarding error recovery and incremental changes. Visual D uses dparser from the Mono-D project, which still seems the most extensive solution.
Jul 12 2017
On 13.07.2017 01:55, FoxyBrown wrote:On Tuesday, 11 July 2017 at 07:16:33 UTC, Rainer Schuetze wrote:It works for me, but takes a couple of seconds to digest all the gtk files. There is no completion before that finishes. I've tried it with a file looking like this: module gtkAll; public import gtk.AboutDialog; public import gtk.AccelGroup; ...On 07.07.2017 19:23, FoxyBrown wrote:No luck. gtk. does nothing intellisense wise. I have all the check boxes checked under language options/intellisense.Hi, I get no intellisense with visual d when using gtk. I use a file that imports all of gtk, like so: module gtk.All; public import gtk.AboutDialog; ... public import gtk.WindowGroup; then I use import gtk = gtk.All but when using gtk. or gtk.WindowGroup. or somegtkWidget. no intellisense ever appears or it appears with only the basic object elements. This makes it very hard to navigate through gtk as I am unfamiliar with most of the nomenclature. Is there any way to get VisualD to properly show the intellisense for these objects and modules? Even if necessarily having to specify direct inclusion. If I just do gtk.gtk.gtk.gtk.gtk.gtk.gtk.... in an empty d file it goes on and on always listing the same intellisense. Changing things like gtk.gtkd.gtk.gtkd.... doesnt change the results. The intellisense listed is ByRecord, Error, Exception, File, Interface, etc. I do not think they are part of gtk.AFAICT the completion has problems with public imports in imported modules: they don't add any symbols. This should be fixed in https://github.com/dlang/visuald/releases/tag/v0.45.0-rc1In any case, it clearly isn't working and there doesn't seem to be any way to correct it. It would be nice if we could precompile intellisense data from a set of modules(e.g., specify that it build an intellisense database from a directory recursively... probably would be faster too). Phobos, gtk, and other libraries generally do not change often enough that it should work well.If you let the compiler generate JSON data for your project (see language options), Visual D can add the contained symbols to the completion lists. You can also add precompiled JSON files (see global options). This doesn't use any scope information, though, so the list can grow enormously. One of the biggest issues I seem to have withVisual D is intellisense not really working correctly, if it works at all, but this isn't a hard problem, is it?You bet it is ;-) It needs to rebuild the compiler front end, just being more friendly regarding error recovery and incremental changes. Visual D uses dparser from the Mono-D project, which still seems the most extensive solution.In the solution.json file, There is this, which only seems to be import modules and enums, no functions are added, maybe that is the problem? I do not have the gtk files in the solution(they are only imported during compilation), do I need to import them in to the solution for everything to work? ( [ { "name" : "gtk.All", "kind" : "module", "file" : "..\\..\\..\\DLang\\GtkD\\generated\\gtkd\\gtk\\All.d", "members" : [ { "name" : "gtk.AboutDialog", "kind" : "import", "line" : 3, "char" : 15 },...] },The project built JSON file only covers the files actually in the project. You can create a full JSON file with the help of rdmd, e.g. rdmd -X gtkd\gtkAll.d That will likely fail due to object file generation or link errors, but should still build the JSON file.
Jul 12 2017
On Thursday, 13 July 2017 at 06:30:07 UTC, Rainer Schuetze wrote:On 13.07.2017 01:55, FoxyBrown wrote:What do I do with the json file when it is created? Where does it go? I'd like to get intellisense to work with gtkD. I tried adding the gtkD but it locked up VS. The files are 10MB+. There are two files. gtkD_all.exe.json gtkD_all.json How do I tell visual D to look in those files to use for intellisense? Visual D has a "Build Phobos Browse Info". Is that essentially what it does but on the phobos src directory?On Tuesday, 11 July 2017 at 07:16:33 UTC, Rainer Schuetze wrote:It works for me, but takes a couple of seconds to digest all the gtk files. There is no completion before that finishes. I've tried it with a file looking like this: module gtkAll; public import gtk.AboutDialog; public import gtk.AccelGroup; ...[...]No luck. gtk. does nothing intellisense wise. I have all the check boxes checked under language options/intellisense.In the solution.json file, There is this, which only seems to be import modules and enums, no functions are added, maybe that is the problem? I do not have the gtk files in the solution(they are only imported during compilation), do I need to import them in to the solution for everything to work? ( [ { "name" : "gtk.All", "kind" : "module", "file" : "..\\..\\..\\DLang\\GtkD\\generated\\gtkd\\gtk\\All.d", "members" : [ { "name" : "gtk.AboutDialog", "kind" : "import", "line" : 3, "char" : 15 },...] },The project built JSON file only covers the files actually in the project. You can create a full JSON file with the help of rdmd, e.g. rdmd -X gtkd\gtkAll.d That will likely fail due to object file generation or link errors, but should still build the JSON file.
Aug 03 2017
On Friday, 4 August 2017 at 01:33:53 UTC, Johnson Jones wrote:On Thursday, 13 July 2017 at 06:30:07 UTC, Rainer Schuetze wrote:I put the files in a dir and told that under the JSON edit box in properties in visual D/studio and eventually it seems that intelligent started working. (it didn't work at first but after a few hours I noticed that I was getting intellisense, not sure if that is what did it or something else I might have fiddled with). How does Visual D use those files? Does the file name have anything to do with it or does it just load any files inside the dir and then search the json for a match? The reason I ask is so I can add other intellisense libraries to it in the future and maybe be a bit more happier with visual D :)On 13.07.2017 01:55, FoxyBrown wrote:What do I do with the json file when it is created? Where does it go? I'd like to get intellisense to work with gtkD. I tried adding the gtkD but it locked up VS. The files are 10MB+. There are two files. gtkD_all.exe.json gtkD_all.json How do I tell visual D to look in those files to use for intellisense? Visual D has a "Build Phobos Browse Info". Is that essentially what it does but on the phobos src directory?On Tuesday, 11 July 2017 at 07:16:33 UTC, Rainer Schuetze wrote:It works for me, but takes a couple of seconds to digest all the gtk files. There is no completion before that finishes. I've tried it with a file looking like this: module gtkAll; public import gtk.AboutDialog; public import gtk.AccelGroup; ...[...]No luck. gtk. does nothing intellisense wise. I have all the check boxes checked under language options/intellisense.In the solution.json file, There is this, which only seems to be import modules and enums, no functions are added, maybe that is the problem? I do not have the gtk files in the solution(they are only imported during compilation), do I need to import them in to the solution for everything to work? ( [ { "name" : "gtk.All", "kind" : "module", "file" : "..\\..\\..\\DLang\\GtkD\\generated\\gtkd\\gtk\\All.d", "members" : [ { "name" : "gtk.AboutDialog", "kind" : "import", "line" : 3, "char" : 15 },...] },The project built JSON file only covers the files actually in the project. You can create a full JSON file with the help of rdmd, e.g. rdmd -X gtkd\gtkAll.d That will likely fail due to object file generation or link errors, but should still build the JSON file.
Aug 03 2017
On 04.08.2017 04:31, Johnson Jones wrote:On Friday, 4 August 2017 at 01:33:53 UTC, Johnson Jones wrote:Yes, more or less the latter. You can also browse the loaded JSON files in the "Object Browser" window.On Thursday, 13 July 2017 at 06:30:07 UTC, Rainer Schuetze wrote:I put the files in a dir and told that under the JSON edit box in properties in visual D/studio and eventually it seems that intelligent started working. (it didn't work at first but after a few hours I noticed that I was getting intellisense, not sure if that is what did it or something else I might have fiddled with). How does Visual D use those files? Does the file name have anything to do with it or does it just load any files inside the dir and then search the json for a match?On 13.07.2017 01:55, FoxyBrown wrote:What do I do with the json file when it is created? Where does it go? I'd like to get intellisense to work with gtkD. I tried adding the gtkD but it locked up VS. The files are 10MB+. There are two files. gtkD_all.exe.json gtkD_all.json How do I tell visual D to look in those files to use for intellisense? Visual D has a "Build Phobos Browse Info". Is that essentially what it does but on the phobos src directory?On Tuesday, 11 July 2017 at 07:16:33 UTC, Rainer Schuetze wrote:It works for me, but takes a couple of seconds to digest all the gtk files. There is no completion before that finishes. I've tried it with a file looking like this: module gtkAll; public import gtk.AboutDialog; public import gtk.AccelGroup; ...[...]No luck. gtk. does nothing intellisense wise. I have all the check boxes checked under language options/intellisense.In the solution.json file, There is this, which only seems to be import modules and enums, no functions are added, maybe that is the problem? I do not have the gtk files in the solution(they are only imported during compilation), do I need to import them in to the solution for everything to work? ( [ { "name" : "gtk.All", "kind" : "module", "file" : "..\\..\\..\\DLang\\GtkD\\generated\\gtkd\\gtk\\All.d", "members" : [ { "name" : "gtk.AboutDialog", "kind" : "import", "line" : 3, "char" : 15 },...] },The project built JSON file only covers the files actually in the project. You can create a full JSON file with the help of rdmd, e.g. rdmd -X gtkd\gtkAll.d That will likely fail due to object file generation or link errors, but should still build the JSON file.
Aug 04 2017
On Friday, 4 August 2017 at 07:27:54 UTC, Rainer Schuetze wrote:On 04.08.2017 04:31, Johnson Jones wrote:It seems to be working. I haven't done any thorough testing but what I have noticed is that it seems to list any functions that match rather than reduce the number. e.g., I have a gtkApplicationWindow called mainWindow. I do mainWindow.getSize(...) It lists all the getSizes that exist. There are 11... but only one for mainWindow. e.g., it shows one for glib, one for atk, etc. Not sure if the json is incomplete or visual D does not try to match the function to the object type it is used on? Not a huge deal but through me off for a second until I realized what was going on. Not ideal but better than nothing. Maybe a simple fix?On Friday, 4 August 2017 at 01:33:53 UTC, Johnson Jones wrote:Yes, more or less the latter. You can also browse the loaded JSON files in the "Object Browser" window.On Thursday, 13 July 2017 at 06:30:07 UTC, Rainer Schuetze wrote:I put the files in a dir and told that under the JSON edit box in properties in visual D/studio and eventually it seems that intelligent started working. (it didn't work at first but after a few hours I noticed that I was getting intellisense, not sure if that is what did it or something else I might have fiddled with). How does Visual D use those files? Does the file name have anything to do with it or does it just load any files inside the dir and then search the json for a match?On 13.07.2017 01:55, FoxyBrown wrote:What do I do with the json file when it is created? Where does it go? I'd like to get intellisense to work with gtkD. I tried adding the gtkD but it locked up VS. The files are 10MB+. There are two files. gtkD_all.exe.json gtkD_all.json How do I tell visual D to look in those files to use for intellisense? Visual D has a "Build Phobos Browse Info". Is that essentially what it does but on the phobos src directory?[...]It works for me, but takes a couple of seconds to digest all the gtk files. There is no completion before that finishes. I've tried it with a file looking like this: module gtkAll; public import gtk.AboutDialog; public import gtk.AccelGroup; ...[...]...[...]The project built JSON file only covers the files actually in the project. You can create a full JSON file with the help of rdmd, e.g. rdmd -X gtkd\gtkAll.d That will likely fail due to object file generation or link errors, but should still build the JSON file.
Aug 05 2017
On 05.08.2017 14:20, Johnson Jones wrote:On Friday, 4 August 2017 at 07:27:54 UTC, Rainer Schuetze wrote:As noted before, the JSON support predates semantic analysis. It doesn't have any scope/symbol lookup information so it just lists matching identifiers. That's sometimes useful (e.g. if an import is still missing), but the semantic analysis result is often more accurate (but much harder to implement). It might be nice to integrate these two approaches, so that Visual D could insert an import automatically when selecting a completion without appropriate import. That's unlikely to happen very soon, though.On 04.08.2017 04:31, Johnson Jones wrote:It seems to be working. I haven't done any thorough testing but what I have noticed is that it seems to list any functions that match rather than reduce the number. e.g., I have a gtkApplicationWindow called mainWindow. I do mainWindow.getSize(...) It lists all the getSizes that exist. There are 11... but only one for mainWindow. e.g., it shows one for glib, one for atk, etc. Not sure if the json is incomplete or visual D does not try to match the function to the object type it is used on? Not a huge deal but through me off for a second until I realized what was going on. Not ideal but better than nothing. Maybe a simple fix?On Friday, 4 August 2017 at 01:33:53 UTC, Johnson Jones wrote:Yes, more or less the latter. You can also browse the loaded JSON files in the "Object Browser" window.On Thursday, 13 July 2017 at 06:30:07 UTC, Rainer Schuetze wrote:I put the files in a dir and told that under the JSON edit box in properties in visual D/studio and eventually it seems that intelligent started working. (it didn't work at first but after a few hours I noticed that I was getting intellisense, not sure if that is what did it or something else I might have fiddled with). How does Visual D use those files? Does the file name have anything to do with it or does it just load any files inside the dir and then search the json for a match?On 13.07.2017 01:55, FoxyBrown wrote:What do I do with the json file when it is created? Where does it go? I'd like to get intellisense to work with gtkD. I tried adding the gtkD but it locked up VS. The files are 10MB+. There are two files. gtkD_all.exe.json gtkD_all.json How do I tell visual D to look in those files to use for intellisense? Visual D has a "Build Phobos Browse Info". Is that essentially what it does but on the phobos src directory?[...]It works for me, but takes a couple of seconds to digest all the gtk files. There is no completion before that finishes. I've tried it with a file looking like this: module gtkAll; public import gtk.AboutDialog; public import gtk.AccelGroup; ...[...]...[...]The project built JSON file only covers the files actually in the project. You can create a full JSON file with the help of rdmd, e.g. rdmd -X gtkd\gtkAll.d That will likely fail due to object file generation or link errors, but should still build the JSON file.
Aug 06 2017
On Sunday, 6 August 2017 at 11:43:17 UTC, Rainer Schuetze wrote:On 05.08.2017 14:20, Johnson Jones wrote:(this is a bit long of a post so take your time(when you have time, I'm in no rush) and get some coffee ;) What about locals not seeming to show up? Not sure if my question got answered or not? separator.addOnButtonPress((Event e, Widget w) { // no intellisense on e and w return true; }); I can follow Event and Widget to peek at the code but that is pretty time consuming. Also, listing all matches does no good. Surely the json output of dmd could be updated so that it gives the hierarchy of the type and then that can simply be matched and only those members that match the hierarchy are shown(or shown first)? e.g., Event e; when I type e. The compiler/debugger must know that Event is of type gdk.Event. If the debugger cannot get that, then I guess everything is fubar'ed. Once it knows that, it should be able to look that up in the json. If not, then the json generation should be updated to add that. This is the gdk.Event listing in the json file I generated for gdk: { "name" : "gdk.Event", "kind" : "module", "file" : "gtkd\\gdk\\Event.d", "members" : [ { "name" : "gdk.Device", "kind" : "import", "line" : 27, "char" : 16, "protection" : "private" }, { ... other imports ... } { "name" : "gtkd.Loader", "kind" : "import", "line" : 38, "char" : 16, "protection" : "private" }, { "name" : "Event", "kind" : "class", "line" : 73, "char" : 8, "members" : [ { "name" : "gdkEvent", "kind" : "variable", "protection" : "protected", "line" : 76, "char" : 22, "deco" : "PS4gtkc8gdktypes8GdkEvent", "offset" : 8 }, { ... other members ... } and it seems that pretty much the json lists all the members that exist. So it should be quite simple for the debugger to figure out what to list rather than just blinding searching the json!? Basically instead of searching the full json, we restrict it to the sub-hierarchy of gdk.Event. This limits the search results and everything is good. That does require us to know that e and Event are suppose to use { "name" : "gdk.Event", "kind" : "module", "file" : "gtkd\\gdk\\Event.d", And I must assume that is where the problem is at. How do we know Event and/or e are gdk.Events during editing? Well, obviously "go to reference" gets it right! so somehow visual D is figuring it out. Since it can open the module when that is done(I use that feature all the time as that seems to be my "intellisense" that works best currently). Since it can open that module it should just have to find that match in the json modules(like the one above) then use the reduced json tree instead of the full tree. It doesn't seem too complicated and all the code seems to be there to do it effectively? While, I guess, module names are not unique and one might have to do a bit more parsing, all that should be pretty direct and basic. Am I on the right track here? I guess I could try to download visual D source and see if I could do that but I imagine I'd waste a lot of my own time unless it's pretty obvious in the source code what is going on. Basically visual D should have, internally, a tree corresponding to the json where it can search to return the proper results and it is just a matter of proper searching?(it seems to just return all results in some cases or no results in others). ------------------------------Part 2---------------------------- I just tried downloading the source code and get "C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\\Common7\Tools\vsvars32.bat" when building build. There is no vsvars32.bat in that directory. There is VsDevCmd and VsMSBuildCmd which I'm not sure if it is a new build system or what. I copyed VsDevCmd to vsvars32 since I do not find that string anywhere in the solution(might be a M$ issue?). I then get "..\bin\Debug\tlb2idl.exe" does not exist which !!!fails!!! the build. Looking at **build.bat** I get c:\l\dmd-1.056\windows\bin\dmd.exe -g tlb2idl.d oleaut32.lib uuid.lib snn.lib kernel32.lib which is definitely not where my dmd is installed. **That seems to be hard coded.** Also in that same file is m:\s\d\cv2pdb\trunk\bin\debug\cv2pdb -D1 tlb2idl.exe tlb2idl_pdb.exe which, I think I have no m drive. Using the installed VisualD's cv2pdb, and running build. I get --------- D:\Repos\visuald-master\tools>c:\d\dmd2\windows\bin\dmd.exe -g tlb2idl.d oleaut32.lib uuid.lib snn.lib kernel32.lib tlb2idl.d(4): Deprecation: module std.c.windows.com is deprecated - Import core.sys.windows.com instead D:\Repos\visuald-master\tools>if errorlevel 1 goto xit D:\Repos\visuald-master\tools>"C:\Program Files (x86)\VisualD\cv2pdb\cv2pdb.exe" -D1 tlb2idl.exe tlb2idl_pdb.exe D:\Repos\visuald-master\tools\tlb2idl_pdb.pdb: cannot load PDB helper DLL ------ There is a tlb2idl.exe now. Copied that to bin\debug. Reran build solution and now it is translating... after that is finished I get ------ WindowsSdkDir=C:\Program Files (x86)\Windows Kits\10\ Error: cannot execute coffimplib, please add to PATH ------ which seems to be !!hardcoded!! set COFFIMPLIB=c:\l\dmc\bin\coffimplib.exe at line 30 in sdk_libs. I don't even have that in my dmc(using dmd2 installer, which wanted to install dmc, but I guess that needs to be updated to install that. I'll hunt for it online). After all that, the build project built without errors. Now trying to build VisualD project I get Building ..\bin\Debug\vsi.lib... win32\handleapi.d(40): Error: found 'hObject' when expecting ')' win32\handleapi.d(41): Error: semicolon expected following function declaration win32\handleapi.d(41): Error: declaration expected, not ')' I remove the _Post_ptr_invalid_ and tried to rebuilt again and got the errors win32\rpcdce.d(1717): Error: undefined identifier `RpcBindingInqAuthClientW`, did you mean alias `RpcBindingInqAuthClient`? win32\rpcdce.d(1718): Error: undefined identifier `RpcBindingInqAuthClientExW`, did you mean alias `RpcBindingInqAuthClientEx`? vsi\vsregkeynames.d(29): Error: undefined identifier `REGKEY_BLENDROOT_CURRENT` vsi\vsregkeynames.d(30): Error: undefined identifier `LREGKEY_BLENDROOT_CURRENT` I imagine this will continue ;/ Seems to be something wonky with the project. These errors seem to be releated to win32? Have you been able to get Visual D to build on a completely fresh install(That is basically what I'm using) or are you using the same system that you've been using since the start? Maybe all these problems is why no one is helping with it? Seems like a lot of trouble(not blaming you or anything, just saying it might be worth fixing these issues). ----------------------------- Fixes: Paths that are hard coded - Either add some type of intelligent search algorithm or put all the hard coded paths in one spot so the user can easily find and build them. Put in the docs the things that are required to build and modify to get things to work. "C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\\Common7\Tools\vsvars32.bat" Try to use others if this doesn't exist. build.bat: Hard coded dmd - simply try to use path first and see if dmd.exe exists in it. Most people using visual D will have dmd installed and it will have added itself to the path c:\l\dmd-1.056\windows\bin\dmd.exe Hard coded cv2pdb m:\s\d\cv2pdb\trunk\bin\debug\cv2pdb -D1 tlb2idl.exe tlb2idl_pdb.exe (change this to standard visual D install C:\Program Files (x86) since most likely the end user will have Visual D installed to the default path. Do not hard code in build.bat though) sdk_libs: Hard coded coffimplib. Not sure what to do here but probably use the dmd.exe as a reference then back track since the dmd2 installer installs dmc relative to it. It doesn't come with coffimplib but maybe it could be added so it exists. set COFFIMPLIB=c:\l\dmc\bin\coffimplib.exe at line 30 in sdk_libs. When these files are missing good error messages should report they are missing(probably checked at the start rather than failing in the middle of the build process. All these errors are from hard coded paths an missing files. Should be easy fixes.On Friday, 4 August 2017 at 07:27:54 UTC, Rainer Schuetze wrote:As noted before, the JSON support predates semantic analysis. It doesn't have any scope/symbol lookup information so it just lists matching identifiers. That's sometimes useful (e.g. if an import is still missing), but the semantic analysis result is often more accurate (but much harder to implement). It might be nice to integrate these two approaches, so that Visual D could insert an import automatically when selecting a completion without appropriate import. That's unlikely to happen very soon, though.On 04.08.2017 04:31, Johnson Jones wrote:It seems to be working. I haven't done any thorough testing but what I have noticed is that it seems to list any functions that match rather than reduce the number. e.g., I have a gtkApplicationWindow called mainWindow. I do mainWindow.getSize(...) It lists all the getSizes that exist. There are 11... but only one for mainWindow. e.g., it shows one for glib, one for atk, etc. Not sure if the json is incomplete or visual D does not try to match the function to the object type it is used on? Not a huge deal but through me off for a second until I realized what was going on. Not ideal but better than nothing. Maybe a simple fix?On Friday, 4 August 2017 at 01:33:53 UTC, Johnson Jones wrote:Yes, more or less the latter. You can also browse the loaded JSON files in the "Object Browser" window.On Thursday, 13 July 2017 at 06:30:07 UTC, Rainer Schuetze wrote:I put the files in a dir and told that under the JSON edit box in properties in visual D/studio and eventually it seems that intelligent started working. (it didn't work at first but after a few hours I noticed that I was getting intellisense, not sure if that is what did it or something else I might have fiddled with). How does Visual D use those files? Does the file name have anything to do with it or does it just load any files inside the dir and then search the json for a match?On 13.07.2017 01:55, FoxyBrown wrote:What do I do with the json file when it is created? Where does it go? I'd like to get intellisense to work with gtkD. I tried adding the gtkD but it locked up VS. The files are 10MB+. There are two files. gtkD_all.exe.json gtkD_all.json How do I tell visual D to look in those files to use for intellisense? Visual D has a "Build Phobos Browse Info". Is that essentially what it does but on the phobos src directory?[...]It works for me, but takes a couple of seconds to digest all the gtk files. There is no completion before that finishes. I've tried it with a file looking like this: module gtkAll; public import gtk.AboutDialog; public import gtk.AccelGroup; ...[...]...[...]The project built JSON file only covers the files actually in the project. You can create a full JSON file with the help of rdmd, e.g. rdmd -X gtkd\gtkAll.d That will likely fail due to object file generation or link errors, but should still build the JSON file.
Aug 06 2017
On 06.08.2017 18:31, Johnson Jones wrote:(this is a bit long of a post so take your time(when you have time, I'm in no rush) and get some coffee ;) What about locals not seeming to show up? Not sure if my question got answered or not?I think there is some misunderstanding about the interaction between the debugger, the semantic engine and the compiler generated JSON information. The short version: there is no interaction at all. The slightly longer version: - the debugger is a component completely different from the editor. It operates on the debug info built into the executable. This represents the information from the last successful build, but this is hardly accessible to the editor. It can get obsolete and wrong if you start editing. - the JSON information is similar to the debug information in that it represents the information from the last successful build, but more accessible to the editor. It gets obsolete and wrong if you start editing, too. In addition it doesn't include any information about local variables, so that you have to analyze the code with other means to make sense of any identifier. - that's the job of the semantic analyzer engine. It updates whenever you change any of the source code. It figures out what type an identifier is by following the appropriate lookup rules, and it can also list its members. So matching it to information also available elsewhere does not really help, because that's not the difficult part.------------------------------Part 2---------------------------- I just tried downloading the source code and get > "C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\\Common7\Tools\vsvars32.bat" when building build.I suspect Visual D doesn't build out of the box with VS2017. I still use VS2013 to avoid dependencies in the resulting binaries on newer versions. See the appveyor.xml how to obtain external dependencies and how to override environment settings. You might also want it to check the logs on Appveyor that builds with VS2013 and VS2015: https://ci.appveyor.com/project/rainers/visuald/build/1.0.138
Aug 06 2017
On Sunday, 6 August 2017 at 19:27:26 UTC, Rainer Schuetze wrote:On 06.08.2017 18:31, Johnson Jones wrote:Yeah, but these locals are variables that haven't changed. It's part of a library that never changes so the information should always be up to date and everything should be consistent with respect to those elements. If it's the semantic analyzers job to report a locals type and all the sub type info, then it's not doing it's job. It should provide coverage in such a way that things that haven't been modified since the last build(like "external" libraries) should be ok to report information because it's safe to assume it's correct. Editing files is an extremely local thing and rarely breaks the semantics of much of the program(it can in extreme cases but usually very rare and less likely the larger the program). If it's still a problem, how about eventually adding an option where we can specify certain json paths as being semantically correct and the semantic engine uses that data as if it were, regardless. It is up to the programmer to make it so. Hence, for something like phobos or gtk or other libraries we won't be modifying, generate the json, stick it in that dir... and the semantic engine uses it regardless of correctness. It matches the locals types up with it and if they match it presents that info. What's the worse that could happen? We get some invalid elements in intellisense? I'm ok with that... as long as they are only wrong if I actually modified the libraries and produced an inconsistent state, which I won't do since I don't modify phobos.(this is a bit long of a post so take your time(when you have time, I'm in no rush) and get some coffee ;) What about locals not seeming to show up? Not sure if my question got answered or not?I think there is some misunderstanding about the interaction between the debugger, the semantic engine and the compiler generated JSON information. The short version: there is no interaction at all. The slightly longer version: - the debugger is a component completely different from the editor. It operates on the debug info built into the executable. This represents the information from the last successful build, but this is hardly accessible to the editor. It can get obsolete and wrong if you start editing. - the JSON information is similar to the debug information in that it represents the information from the last successful build, but more accessible to the editor. It gets obsolete and wrong if you start editing, too. In addition it doesn't include any information about local variables, so that you have to analyze the code with other means to make sense of any identifier. - that's the job of the semantic analyzer engine. It updates whenever you change any of the source code. It figures out what type an identifier is by following the appropriate lookup rules, and it can also list its members. So matching it to information also available elsewhere does not really help, because that's not the difficult part.ok, I'll see what I can do with it.------------------------------Part 2---------------------------- I just tried downloading the source code and get > "C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\\Common7\Tools\vsvars32.bat" when building build.I suspect Visual D doesn't build out of the box with VS2017. I still use VS2013 to avoid dependencies in the resulting binaries on newer versions. See the appveyor.xml how to obtain external dependencies and how to override environment settings. You might also want it to check the logs on Appveyor that builds with VS2013 and VS2015: https://ci.appveyor.com/project/rainers/visuald/build/1.0.138
Aug 06 2017
On 06.08.2017 22:18, Johnson Jones wrote:On Sunday, 6 August 2017 at 19:27:26 UTC, Rainer Schuetze wrote:Yeah, getting some additional information from JSON files could work, but it's not so easy to make the connection. The JSON file does not list any locals, so you still have to make sense of an identifier. If you find it's type (not vailable in JSON), listing its members is not a big deal. I think time is better invested at improving the semantic engine, though in the long run, the dmd compiler is supposed to be usable as a library (but getting it to a point where it can be integrated with an IDE is way further ahead IMO). So, if you can provide full source files instead of single line snippets of things that don't work, it will likely be a lot easier to reproduce and fix the semantic engine. Also, you might want to add them as reports to https://issues.dlang.org/ for component visuald so they don't get lost.On 06.08.2017 18:31, Johnson Jones wrote:Yeah, but these locals are variables that haven't changed. It's part of a library that never changes so the information should always be up to date and everything should be consistent with respect to those elements. If it's the semantic analyzers job to report a locals type and all the sub type info, then it's not doing it's job. It should provide coverage in such a way that things that haven't been modified since the last build(like "external" libraries) should be ok to report information because it's safe to assume it's correct. Editing files is an extremely local thing and rarely breaks the semantics of much of the program(it can in extreme cases but usually very rare and less likely the larger the program). If it's still a problem, how about eventually adding an option where we can specify certain json paths as being semantically correct and the semantic engine uses that data as if it were, regardless. It is up to the programmer to make it so. Hence, for something like phobos or gtk or other libraries we won't be modifying, generate the json, stick it in that dir... and the semantic engine uses it regardless of correctness. It matches the locals types up with it and if they match it presents that info. What's the worse that could happen? We get some invalid elements in intellisense? I'm ok with that... as long as they are only wrong if I actually modified the libraries and produced an inconsistent state, which I won't do since I don't modify phobos.(this is a bit long of a post so take your time(when you have time, I'm in no rush) and get some coffee ;) What about locals not seeming to show up? Not sure if my question got answered or not?I think there is some misunderstanding about the interaction between the debugger, the semantic engine and the compiler generated JSON information. The short version: there is no interaction at all. The slightly longer version: - the debugger is a component completely different from the editor. It operates on the debug info built into the executable. This represents the information from the last successful build, but this is hardly accessible to the editor. It can get obsolete and wrong if you start editing. - the JSON information is similar to the debug information in that it represents the information from the last successful build, but more accessible to the editor. It gets obsolete and wrong if you start editing, too. In addition it doesn't include any information about local variables, so that you have to analyze the code with other means to make sense of any identifier. - that's the job of the semantic analyzer engine. It updates whenever you change any of the source code. It figures out what type an identifier is by following the appropriate lookup rules, and it can also list its members. So matching it to information also available elsewhere does not really help, because that's not the difficult part.
Aug 07 2017
On Monday, 7 August 2017 at 18:06:37 UTC, Rainer Schuetze wrote:On 06.08.2017 22:18, Johnson Jones wrote:Could Dscanner not be used? https://github.com/dlang-community/D-Scanner The "--ast" or "--xml" options will dump the complete abstract syntax tree of the given source file to standard output in XML format. Simply match the source line number up with the ast, extract the type. This type then is used as a look up in the JSON(it should be there somewhere, if not, update dmd to add type information so cross referencing can be used). IMO, DMD should be able to generate basically every cross-relation that one needs to do proper debugging. When it evaluates a mixin it can generate whatever info is required and even allow debugging mixins since dmd invokes dmd again to generate the mixin output, insert a debugger in between. It seems that the main problem is that dmd itself is not very well designed to support these types of features. Maybe that is the place to start? Basically every line in the source code to correspond to a line in the binary(although, not a one to one function and not even a function at all, one can still encode such a mapping to find out what is where) and vice versa. All type info, mixin expansions, etc should be easily understood. All this has to work else dmd couldn't compile them. The only problem seems to be dmd extracting and presenting the information in such a way that Visual D can understand it? In a sense, I don't see why any semantic analysis has to be done. Everything is already done by DMD and it will do it perfectly(because it has to). It would probably be better to add the proper modifications to DMD so that it can self-regulate with changes in DMD or the grammar. This prevents having to update any separate utility every time dmd changes something. I don't know if dmd as a library will really add any thing new unless it already has the functionality to do what is required... but if that's the case it should also be able, then to output all the required info to a file that Visual D could use, so it's just a performance difference. As far as source code is concerned, it happens on any project, so any project should exhibit such problems. Of course, mixin issues will only happen when mixins are used. I think any typical use of Visual D tends to demonstrate some issue that needs to be resolved. These are not issues that rarely pop up but are pretty much an every day thing. IMO, there is something fundamentally broke with Visual D or DMD as regard to debugging capabilities. I know some of it is with dmd and the power that be don't care because they don't use modern debugging techniques... so it doesn't effect them. They are probably experienced enough programs and don't write any real apps in D either(exclude utilities are libraries that don't really use a wide variety of things) to have these types of issues... and when they do they either know how to fix them, use their old school debugging methods, or just work through them... none of which is acceptable for me or the average user of D. (and I seriously doubt they have probably even used Visual D, much less for any serious project) As a case in point: mixin debugging. This is necessary. It is no different than normal debugging. Where would modern programming be without debuggers? Well, that is where we are at with mixins. We have no real way to debug them. I use them all the time and have to really be careful with what I'm doing and use stupid tricks to debug them. Mainly string mixins, which is far more time consuming than getting an error at some line number. I've learned now that I should use write them as normal runtime functions first and then once they work to make them ctfe. But mixin debugging should be easy. After all, it's just a d program inside a d program. dmd compiles it internally, but if dmd had an "internal" debugger then we could debug it and get better results. In a since, it's just back tracing anyways. dmd -> mixin -> dmd -> mixin output <= <= If the internal dmd would keep track of whats going on it could map the output line numbers to the input and we could debug the output(which is effectively inserted in to the main source code directly in a "temp" file(dmd may obfuscate that process but that is what effectively is going on))... Visual D could link errors to the original mixin through the line mapping and even open out the generated output in a view for us to see what the mixin outputted. Of course, all this is not so simple but it's not so hard... just work(which I guess is the hard part). My guess is that because dmd was designed a long time ago that it didn't take in to account what might be, and hence we have what we have... which is great on one hand and sorry on the other. I would think that one of the most important things that the D foundation would be working on besides bugs in DMD and language design issues is a proper IDE and debugger... but that doesn't seem to be the case. Anyways, I've ranted long enough... sorry...On Sunday, 6 August 2017 at 19:27:26 UTC, Rainer Schuetze wrote:Yeah, getting some additional information from JSON files could work, but it's not so easy to make the connection. The JSON file does not list any locals, so you still have to make sense of an identifier. If you find it's type (not vailable in JSON), listing its members is not a big deal. I think time is better invested at improving the semantic engine, though in the long run, the dmd compiler is supposed to be usable as a library (but getting it to a point where it can be integrated with an IDE is way further ahead IMO). So, if you can provide full source files instead of single line snippets of things that don't work, it will likely be a lot easier to reproduce and fix the semantic engine. Also, you might want to add them as reports to https://issues.dlang.org/ for component visuald so they don't get lost.On 06.08.2017 18:31, Johnson Jones wrote:Yeah, but these locals are variables that haven't changed. It's part of a library that never changes so the information should always be up to date and everything should be consistent with respect to those elements. If it's the semantic analyzers job to report a locals type and all the sub type info, then it's not doing it's job. It should provide coverage in such a way that things that haven't been modified since the last build(like "external" libraries) should be ok to report information because it's safe to assume it's correct. Editing files is an extremely local thing and rarely breaks the semantics of much of the program(it can in extreme cases but usually very rare and less likely the larger the program). If it's still a problem, how about eventually adding an option where we can specify certain json paths as being semantically correct and the semantic engine uses that data as if it were, regardless. It is up to the programmer to make it so. Hence, for something like phobos or gtk or other libraries we won't be modifying, generate the json, stick it in that dir... and the semantic engine uses it regardless of correctness. It matches the locals types up with it and if they match it presents that info. What's the worse that could happen? We get some invalid elements in intellisense? I'm ok with that... as long as they are only wrong if I actually modified the libraries and produced an inconsistent state, which I won't do since I don't modify phobos.(this is a bit long of a post so take your time(when you have time, I'm in no rush) and get some coffee ;) What about locals not seeming to show up? Not sure if my question got answered or not?I think there is some misunderstanding about the interaction between the debugger, the semantic engine and the compiler generated JSON information. The short version: there is no interaction at all. The slightly longer version: - the debugger is a component completely different from the editor. It operates on the debug info built into the executable. This represents the information from the last successful build, but this is hardly accessible to the editor. It can get obsolete and wrong if you start editing. - the JSON information is similar to the debug information in that it represents the information from the last successful build, but more accessible to the editor. It gets obsolete and wrong if you start editing, too. In addition it doesn't include any information about local variables, so that you have to analyze the code with other means to make sense of any identifier. - that's the job of the semantic analyzer engine. It updates whenever you change any of the source code. It figures out what type an identifier is by following the appropriate lookup rules, and it can also list its members. So matching it to information also available elsewhere does not really help, because that's not the difficult part.
Aug 07 2017
Rainer Schuetze <r.sagitario gmx.de> On 07.08.2017 21:56, Johnson wrote:Dscanner is more a lint-like tool, not usually used for Intellisense. That's rather done by DCD (https://github.com/dlang-community/DCD). Last time I checked, DCD was well behind D_Parser (a fork of https://github.com/aBothe/D_Parser) used by Visual D: no mixins, CTFE, UFCS, limited template support.So, if you can provide full source files instead of single line snippets of things that don't work, it will likely be a lot easier to reproduce and fix the semantic engine. Also, you might want to add them as reports to https://issues.dlang.org/ for component visuald so they don't get lost.Could Dscanner not be used? https://github.com/dlang-community/D-Scanner The "--ast" or "--xml" options will dump the complete abstract syntax tree of the given source file to standard output in XML format.Simply match the source line number up with the ast, extract the type. This type then is used as a look up in the JSON(it should be there somewhere, if not, update dmd to add type information so cross referencing can be used). IMO, DMD should be able to generate basically every cross-relation that one needs to do proper debugging. When it evaluates a mixin it can generate whatever info is required and even allow debugging mixins since dmd invokes dmd again to generate the mixin output, insert a debugger in between. It seems that the main problem is that dmd itself is not very well designed to support these types of features. Maybe that is the place to start? Basically every line in the source code to correspond to a line in the binary(although, not a one to one function and not even a function at all, one can still encode such a mapping to find out what is where) and vice versa. All type info, mixin expansions, etc should be easily understood. All this has to work else dmd couldn't compile them. The only problem seems to be dmd extracting and presenting the information in such a way that Visual D can understand it? In a sense, I don't see why any semantic analysis has to be done. Everything is already done by DMD and it will do it perfectly(because it has to). It would probably be better to add the proper modifications to DMD so that it can self-regulate with changes in DMD or the grammar. This prevents having to update any separate utility every time dmd changes something. I don't know if dmd as a library will really add any thing new unless it already has the functionality to do what is required... but if that's the case it should also be able, then to output all the required info to a file that Visual D could use, so it's just a performance difference.Again, precompiled information doesn't help while you edit code. Long term the DMD frontend can be used, but one major problem with using it right now is that it bails out if it cannot parse the code, so it won't even try to give information about identifiers at the current edit location. There is work being done on that, but currently more directed towards tools like d-scanner.As far as source code is concerned, it happens on any project, so any project should exhibit such problems. Of course, mixin issues will only happen when mixins are used. I think any typical use of Visual D tends to demonstrate some issue that needs to be resolved. These are not issues that rarely pop up but are pretty much an every day thing. IMO, there is something fundamentally broke with Visual D or DMD as regard to debugging capabilities. I know some of it is with dmd and the power that be don't care because they don't use modern debugging techniques... so it doesn't effect them. They are probably experienced enough programs and don't write any real apps in D either(exclude utilities are libraries that don't really use a wide variety of things) to have these types of issues... and when they do they either know how to fix them, use their old school debugging methods, or just work through them... none of which is acceptable for me or the average user of D. (and I seriously doubt they have probably even used Visual D, much less for any serious project) As a case in point: mixin debugging. This is necessary. It is no different than normal debugging. Where would modern programming be without debuggers? Well, that is where we are at with mixins. We have no real way to debug them. I use them all the time and have to really be careful with what I'm doing and use stupid tricks to debug them. Mainly string mixins, which is far more time consuming than getting an error at some line number. I've learned now that I should use write them as normal runtime functions first and then once they work to make them ctfe. But mixin debugging should be easy. After all, it's just a d program inside a d program. dmd compiles it internally, but if dmd had an "internal" debugger then we could debug it and get better results. In a since, it's just back tracing anyways. dmd -> mixin -> dmd -> mixin output <= <= If the internal dmd would keep track of whats going on it could map the output line numbers to the input and we could debug the output(which is effectively inserted in to the main source code directly in a "temp" file(dmd may obfuscate that process but that is what effectively is going on))... Visual D could link errors to the original mixin through the line mapping and even open out the generated output in a view for us to see what the mixin outputted. Of course, all this is not so simple but it's not so hard... just work(which I guess is the hard part).There have been several proposals to help debugging mixins, here's one of them: https://issues.dlang.org/show_bug.cgi?id=5051 Visual D even highlights *.mixin files as D code...My guess is that because dmd was designed a long time ago that it didn't take in to account what might be, and hence we have what we have... which is great on one hand and sorry on the other. I would think that one of the most important things that the D foundation would be working on besides bugs in DMD and language design issues is a proper IDE and debugger... but that doesn't seem to be the case. Anyways, I've ranted long enough... sorry...
Aug 09 2017
On 06.08.2017 21:27, Rainer Schuetze wrote:I have updated the build scripts and the C to D conversion to also work with VS2017 and Windows SDK 10.0.15063.0.------------------------------Part 2---------------------------- I just tried downloading the source code and get > "C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\\Common7\Tools\vsvars32.bat" when building build.I suspect Visual D doesn't build out of the box with VS2017. I still use VS2013 to avoid dependencies in the resulting binaries on newer versions.
Aug 10 2017
On Thursday, 10 August 2017 at 07:05:26 UTC, Rainer Schuetze wrote:On 06.08.2017 21:27, Rainer Schuetze wrote:Awesome! I think I got it to build! I had a few issues. I still had to fix a few hard coded paths I listed above(I think it was mainly the tools/build.bat: c:\d\dmd2\windows\bin\dmd.exe -g tlb2idl.d oleaut32.lib uuid.lib snn.lib kernel32.lib if errorlevel 1 goto xit "C:\Program Files (x86)\VisualD\cv2pdb\cv2pdb.exe" -D1 tlb2idl.exe tlb2idl_pdb.exe :xit which had hard coded paths for dmd2 and cv2pdb. A new issue was with Must fix up vsct or add proper vssdk path to visuald.visualdproj: C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VSSDK\VisualStudioIntegration\Tools\Bin\vsct.exe here: (my modified version) <File path="Resources\pkgcmd.vsct" customcmd="set VSSDKInstall=%VSSDK140Install% if "%VSSDKInstall%" == "" set VSSDKInstall=%VSSDK120Install% if "%VSSDKInstall%" == "" set VSSDKInstall=%VSSDK110Install% if "%VSSDKInstall%" == "" set VSSDKInstall=%VSSDK100Install% if "%VSSDKInstall%" == "" set VSSDKInstall=%VSSDK90Install% if "%VSSDKInstall%" == "" set VSSDKInstall=C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VSSDK\ <- this line set VSCT=%VSSDKInstall%\VisualStudioIntegration\Tools\Bin\VSCT.exe set VSCT=C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VSSDK\VisualStudioIntegration\Tools\Bin\vsct.exe if not exist "%VSCT%" goto no_VSCT "%VSCT%" $(InputPath) $(InputDir)\$(InputName).cto -I"%VSSDKInstall%\VisualStudioIntegration\Common\Inc" goto reportError which was generating pkgcmd.cto.build like (premod) set PATH=C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.10.25017\bin\HostX86\x86;C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE;C:\Program Files (x86)\Windows Kits\8.1\bin\x86;C:\D\dmd2\windows\bin;%PATH% set VSSDKInstall=%VSSDK140Install% if "%VSSDKInstall%" == "" set VSSDKInstall=%VSSDK120Install% if "%VSSDKInstall%" == "" set VSSDKInstall=%VSSDK110Install% if "%VSSDKInstall%" == "" set VSSDKInstall=%VSSDK100Install% if "%VSSDKInstall%" == "" set VSSDKInstall=%VSSDK90Install% if "%VSSDKInstall%" == "" set VSSDKInstall=C:\l\vssdk set VSCT=%VSSDKInstall%\VisualStudioIntegration\Tools\Bin\VSCT.exe So, I guess VSSDKx0Install isn't set on my system because it was always looking for vsct in C:\l\vssdk. Fix that and everything built! Now the question is, what do I do with this? Is there any automated way to update VisualD after a build or someway to simultaneously debug visualD when something happens in another project? Basically, how to make it all seamless debug app/fix visualD cycle? Or do you just manually do all the work? I figure copying visualD over to the install dir requires stopping VS since visualD.dll and others will probably be in use. It would be nice, say, to be able to break in to visualD's source when debugging to to get at specific parts of visual D like how it displays watches so I can more quickly fix things rather than having to learn how visual D is put together before I actually start investigating issues or enhancements. Thanks again! Maybe I can contribute a little to Visual D in the future ;) I saw all your other replies, thanks! I got them. I might reply to a few later if I get some time. I'll spend a little time trying to figure out what's going on and how visual D is setup and where the main bulk of the code for visual studio exists and hopefully it will make enough sense to get somewhere. Thanks!I have updated the build scripts and the C to D conversion to also work with VS2017 and Windows SDK 10.0.15063.0.------------------------------Part 2---------------------------- I just tried downloading the source code and get > "C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\\Common7\Tools\vsvars32.bat" when building build.I suspect Visual D doesn't build out of the box with VS2017. I still use VS2013 to avoid dependencies in the resulting binaries on newer versions.
Aug 10 2017
On 10.08.2017 15:47, Johnson wrote:On Thursday, 10 August 2017 at 07:05:26 UTC, Rainer Schuetze wrote:Sorry, this is an outdated build batch. tlb2idl is also built by the build-project in the solution. I'll better delete this batch.On 06.08.2017 21:27, Rainer Schuetze wrote:Awesome! I think I got it to build! I had a few issues. I still had to fix a few hard coded paths I listed above(I think it was mainly the tools/build.bat: c:\d\dmd2\windows\bin\dmd.exe -g tlb2idl.d oleaut32.lib uuid.lib snn.lib kernel32.lib if errorlevel 1 goto xit "C:\Program Files (x86)\VisualD\cv2pdb\cv2pdb.exe" -D1 tlb2idl.exe tlb2idl_pdb.exe :xit which had hard coded paths for dmd2 and cv2pdb.I have updated the build scripts and the C to D conversion to also work with VS2017 and Windows SDK 10.0.15063.0.------------------------------Part 2---------------------------- I just tried downloading the source code and get > "C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\\Common7\Tools\vsvars32.bat" when building build.I suspect Visual D doesn't build out of the box with VS2017. I still use VS2013 to avoid dependencies in the resulting binaries on newer versions.A new issue was with Must fix up vsct or add proper vssdk path to visuald.visualdproj: C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VSSDK\VisualStudioIntegration\Tools\Bin\vsct.exe[...]set VSSDKInstall=%VSSDK140Install% if "%VSSDKInstall%" == "" set VSSDKInstall=%VSSDK120Install% if "%VSSDKInstall%" == "" set VSSDKInstall=%VSSDK110Install% if "%VSSDKInstall%" == "" set VSSDKInstall=%VSSDK100Install% if "%VSSDKInstall%" == "" set VSSDKInstall=%VSSDK90Install% if "%VSSDKInstall%" == "" set VSSDKInstall=C:\l\vssdk set VSCT=%VSSDKInstall%\VisualStudioIntegration\Tools\Bin\VSCT.exe So, I guess VSSDKx0Install isn't set on my system because it was always looking for vsct in C:\l\vssdk. Fix that and everything built!This is missing the check for VSSDK150Install which is set by the vcvars32.bat of VS2017. I've added that.Now the question is, what do I do with this? Is there any automated way to update VisualD after a build or someway to simultaneously debug visualD when something happens in another project?I usually debug Visual D as described at http://rainers.github.io/visuald/visuald/BuildFromSource.html under "Deployment", but that doesn't work for VS2017 anymore due to the private registry of VS. AFAICT the "official" way is to have a package definition in a user extension folder, but that never worked for me (or I haven't tried enough because the other way worked, too). If you replace the standard installed DLL with a debug version, VS can get quite slow. This is mainly because the debug version writes a log-file visuald.log into the folder where you started devenv from. You can also attach a debugger to a running devenv process. If you are using a release build of visuald with optimizations, debug information can be a lot more confusing than without, though.Basically, how to make it all seamless debug app/fix visualD cycle? Or do you just manually do all the work? I figure copying visualD over to the install dir requires stopping VS since visualD.dll and others will probably be in use. It would be nice, say, to be able to break in to visualD's source when debugging to to get at specific parts of visual D like how it displays watches so I can more quickly fix things rather than having to learn how visual D is put together before I actually start investigating issues or enhancements.I guess you might have noticed, but to make sure you don't get lost in the dependencies: https://github.com/rainers/D_Parser/tree/visuald I usually debug this by starting DParserCOMServer.exe from within the solution, then kill all other running instances. When you edit code in Visual D, it will reconnect to the debug instance. - the debug engine is written in C++: https://github.com/rainers/mago Debugging the Concord extension (MagoNatCC built in configuration "Debug StaticDE") is easiest: just copy the DLL bin\Win32\Debug\MagoNatCC.dll to <VSInstall>\Common7\Packages\Debugger, start debugging in another devenv process and attach the debugger to this other process. - CodeView to PDB conversion for builds with -m32 is done by cv2pdb: https://github.com/rainers/cv2pdbThanks again! Maybe I can contribute a little to Visual D in the future ;)Looking forward to your pull requests!I saw all your other replies, thanks! I got them. I might reply to a few later if I get some time. I'll spend a little time trying to figure out what's going on and how visual D is setup and where the main bulk of the code for visual studio exists and hopefully it will make enough sense to get somewhere. Thanks!
Aug 10 2017