GList

[juliagraphics]

GList

[vtjnash]

What's the use case? Current GSList exists only as an implementation detail (and works compatibly with GList due to common layout)

[tknopp]

https://developer.gnome.org/gtksourceview/stable/GtkSourceCompletionContext.html
needs a GList* proposals But what means common layout? The prevpointer is missing.

[vtjnash]

If you don't need to read prev, it doesn't matter

[tknopp]

Thats true. But if gtk_source_completion_context_add_proposals does read prev it makes bang...

[vtjnash]

Yep. But since gslist is currently an implementation detail, it does not correctly create lists from Julia->C only C->Julia.

[vtjnash]

If I rewrite GList using the new mutable interface, this can be done in a convenient way. I'll try after the weekend when I have more computer access

[tknopp]

Sounds great!

I am still exploring the API of GtkSourceView and hopefully I get code completion working which seems to require #56. Here is a screenshot of a test program using GtkSourceView in Julia:

[tknopp]

GtkRadioToolButton takes a GSList pointer as argument

[vtjnash]

technically yes, but in actual usage, it doesn't seem to be very logical. see existing GtkRadioButton Julia wrapper

[vtjnash]

Forgot to mention: having an IDE written entirely in Julia (+ fairly standard libraries) is AWESOME.

[tknopp]

:-) Still exploring if this is actually feasible. The natural thing to tackle this would be to use a mature language/toolkit (e.g. C++/Qt). But this simply would be a lot less fun than doing it in Julia ;-)

[timholy]

I figured this was your master plan :-) 💯

Doing it all in Julia may make it easier to interact with the debugger, when that lands.

And if you want to tackle it in Qt, how will that be different from Julia Studio?

[tknopp]

@timholy Right. Julia Studio took the complete other approach. Take something working and strip down to make it a Julia IDE. This is great for getting the first 80%. But when it gets to the details this can get quite complicated.

On the other hand the Julia/Gtk.jl also has many pitfalls:

• Non-blocking UI (No threading in Julia)
• Getting Jameson to land precompiled packages ;-)
• Getting Gtk compiled on all platforms including third-party libraries will be more complicated.

However, I am still not entirely sure how much energy I can put into it and in what form to release it.

[timholy]

2 and 3 will clearly come with time. The first is a deeper problem. But, could you simply run the GUI in a second process (addprocs)?

@vtjnash, precompiled packages are not necessarily your burden alone to carry! I like the idea of trying to get a GSoC student to tackle it, unless you don't like that idea (you would surely have to answer some questions...).

[tknopp]

Doing it in another process makes GUI programming a lot more complicated. Using@async kind of works but there are things that can block the schedular (e.g. Pkg.calls).

Maybe we should have an examples/ folder in Gtk.jl where I can put a typical example of something one would typically solve with threads. Then we can discuss this hands on. And in the end we need documentation in the form of examples for such common things anyway.

[vtjnash]

Doing it with threads is painful since you have to wrap most things in gdk_threads_enter()/gdk_threads_leave(), or just use a single thread to access the GUI, as which point it probably might as well be in a separate process (e.g. addprocs)

I've got some support for precompiled packages in my recent pull request :). Of course, if we can get someone to tackle the issues blocking the ability to do more caching such as JuliaLang/julia#265 and JuliaLang/julia#1268, all the better.

[tknopp]

I am not totally sure how important threads are. In my IDE project (https://github.com/tknopp/Julietta.jl) it seems to be not a big issue as I let the terminal run in a different process. And in general the @async method seems to work better than I thought.

Package precompilation is absolutely awesome. This is one of the last showstoppers in Julia currently. [ +Debugger +AnAwsomeIDE :-) ]

[timholy]

Exciting stuff, @vtjnash! And I agree with your sense that these are among the very few remaining big-ticket items, @tknopp.