Re: Mono-D v0.5.1.2 - Completion/Parameter insight improvements
On 2013-02-25 16:25, alex wrote: Yep, that's the one I fixed recently. Aha, cool. I'll have to give it a try. BTW, is the Xamarin Studio IDE free? -- /Jacob Carlborg
Re: Mono-D v0.5.1.2 - Completion/Parameter insight improvements
On 2013-02-25 05:31, alex wrote:
Hi folks,
I recently just announced new versions only on G+, but well,
might be helpful to do it over here either! :)
So, now that I've ported Mono-D to the fresh recently released
version of Xamarin Studio aka MonoDevelop 4.0, I made some
further progress regarding code completion parser library
efficiency..
Kinda embarassing to let Mono-D support huge amounts of slighty
advanced completion/building/formatting features, but not
simple ones which occurred in one of Walter's D tech talks on
component programming in D (see
http://www.youtube.com/watch?v=0cX1f41Fnkc):
void main()
{
stdin.byLine(KeepTerminator.yes).
map!(a = a.idup).
array.
sort.
copy(stdout.lockingTextWriter());
}
By now, only the first statement line can be completed handled
entirely. array, sort and copy shouldn't be problematic either
but the map function is still causing a lot of confusion to the
semantics engine..well, I try to keep it going - meanwhile,
please keep 'contributing' bug reports! Also smaller completion
issues, I want to know all of 'em! ;)
http://mono-d.alexanderbothe.com/?p=896
https://github.com/aBothe/Mono-D/issues
I did a quick test of Xamarin Studio with Mono-D, in general everything
seems to work better and faster. I'll give a more a throughout testing
later.
Good job.
--
/Jacob Carlborg
Re: Crystal
On 2013-02-21 21:37, Jesse Phillips wrote: Not sure how similar all the goals are (dynamic with static benefits) but there is Magpie: http://magpie.stuffwithstuff.com/ Doesn't that run on the JVM? -- /Jacob Carlborg
Re: D 2.062 release
On 2013-02-19 22:01, Walter Bright wrote: Yes, I do use a script. The script has to copy all the correct files over to the right place. VERSION is a new file in a new place, and the script needed updating to copy that one. Automation is great, and I use it. But files appear, disappear, and change directory from release to release, and so the scripts must change as well. Yeah, that's true. -- /Jacob Carlborg
Re: D 2.062 release
On 2013-02-18 08:31, Walter Bright wrote: As long as it isn't written in Ruby :-) I was not referring to what's usually called a scripting language. I was referring to a script, regardless of language. -- /Jacob Carlborg
Re: D 2.062 release
On 2013-02-18 10:02, Joshua Niehus wrote: On Monday, 18 February 2013 at 07:31:53 UTC, Walter Bright wrote: As long as it isn't written in Ruby :-) But more seriously, a D tool to do it might be interesting. Here is a simpleton hack: ### RUBY require nokogiri require open-uri # provided the urls are given changes_new_features_url = http://...blah blah... d_runtime_fixes_url = http://...blah blah... phobos_fixes_url = http://...blah blah... def get_summaries(url) summaries = [] page = Nokogiri::HTML(open(url)) table = page.css(.bz_buglist) rows = table.css(tr) rows.each do |row| summary = row.css(td:last-child).text.strip summaries summary if !summary.empty? end summaries end puts \nChanges and New Features: puts get_summaries(changes_new_features_url) puts \nD Runtime Fixes: puts get_summaries(d_runtime_fixes_url) puts \nPhobos Fixes: puts get_summaries(phobos_fixes_url) ### END I guess the correct approach is to use Bugzilla's REST api, but its 1am... and this might be good enough? This time it wasn't me :) -- /Jacob Carlborg
Re: Crystal
On 2013-02-18 13:46, Ary Borenszweig wrote: In the order it was analyzed. Same as in Ruby. I see. -- /Jacob Carlborg
Re: D 2.062 release
On 2013-02-19 07:25, Kapps wrote: Personally, I just wish there was a quick blurb at the top of the changelog indicating the highlights of this release. For example, with 2.058, the very first two lines of the changelog were: Add new = lambda syntax. Allow 1.userproperty syntax. NOTE: 1.f is no longer a float literal, add a 0. You can look at that and decide Awesome, new lambda syntax and UFCS!. You get a quick 10-20 lines indicating what you need to know about that release, what's interesting about it, and what the new features or most important bug fixes were. For the people who care, you can then see bug fixes / larger list of changes at the bottom (I personally don't have a preference as to whether they'd be on the same page or just a bugzilla link). However the really important thing is the quick blurb at the top. For example, with this release, something about how 'in ref' is now supported, how you can document unittests and have them appear with the documentation of the above symbol, improved JSON output, and unittests being allowed in interfaces. This is just a quick 10 line overview of some of the highlights of this release. Not necessarily just new features either. For example, if example bug#314 was fixed, there is absolutely no way I would know about it given that it's buried in the list of bug fixes, even though it has affected almost every single D user at one point and would definitely be considered a highlight. I agree. I think documenting mixins was added in this release. -- /Jacob Carlborg
Re: Crystal
On 2013-02-17 08:46, Paulo Pinto wrote: Have you looked into Ruby Motion or Mirah as well? Or MacRuby. It's free (as in free beer) and open source, not something that Ruby Motion is. -- /Jacob Carlborg
Re: Crystal
On 2013-02-17 14:21, Paulo Pinto wrote: My problem with MacRuby and Ruby Motion is they are tied to Mac OS X. Yeah, I agree. But developing for iOS is pretty tied to Mac OS X anyway. -- /Jacob Carlborg
Re: Crystal
On 2013-02-17 17:34, Ary Borenszweig wrote: As I replied to Denis, you can specify type restrictions in functions and methods. def foo(x : Int) 1 end foo Hello # Gives a compile error It works similar to overloaded templates: you don't specify the type of the function, but which types you can give to it. In the case of Int, of course it will always just accept an Int. But you can specify for example def foo(x : Enumerable) end Yeah, I saw there's explicit static typing. And there's a special restriction, self, that will only match for the owner of the method. This is used for example in the Comparable module: https://github.com/manastech/crystal/blob/master/std/comparable.cr So in that case self would evaluate, at compile time, to whatever Comparable is mixed in to? I thought it was supported but it's not. It would be very easy to support it, but it would execute at run time, as if you had put it before the class declaration. That code will be executed as soon as the file has been loaded using require? However, there's another thing I didn't mention in that wiki page and that is macros. You can write; --- macro define_something def something; 1; end end define_something() # This defines the something method something() # And this invokes it --- Yeah, I saw that. Again, this is different from Ruby. Macros are executed at compile time. You can pass arguments to them, and their type will be the AST node of the expression you give them. They must return a String (for now), and it will be mixed in the program (later we'll support returning AST nodes directly). We use macros for attr_accessor and the like: https://github.com/manastech/crystal/blob/master/std/object.cr Just note that this is an experimental feature, and for now only variables, strings and symbols are allowed for macros. Macros can execute arbitrary code and have access to what you defined in your program. That means they can open a file, read/write a database and so on. I believe this can be very powerful for metaprogramming. (this is inspired mainly from Lisp) This looks cool. If you don't need them in Ruby I don't see why would you need them in Crystal. You don't need them in Ruby because it's dynamically typed. The only use of interfaces is to satisfy the compiler. But since Crystal is mostly duck-typed interfaces have no use. But it does support explicit static typing. It doesn't look easy to restrict a method for a given type for something like an interface. So what will happen is one use duck typing and it will basically be the same as templates without constrains. Another use is probably performance, and we are still considering how to fit everything together. We are writing code in Crystal and see where it's slow, and think of the most little change that's not a burden for the programmer that can help speed up compilation times. * Is Ruby code supposed to be able to run of out the box in Crystal? That is can I take arbitrary Ruby code and compile it with Crystal and expect it to work. If that's the case, what's currently supported and what's not supported? You probably won't have eval, define_method and so on. You will be able to do some of those things with macros, but it's not the same. Most Ruby code should run out of the box, unless something is missing from the standard library. For example I tried running this code: https://gist.github.com/havenwood/4724778 (removing the Time.now lines, because we don't have that yet) and it just worked. And it was much faster than all of the other languages. Our idea was to make a language as similar as Ruby, not with the intention of compiling Ruby. But accidentally (or not :-P) it is happening, slowly. I see. -- /Jacob Carlborg
Re: Crystal
On 2013-02-17 21:22, Ary Borenszweig wrote: Since it's not yet implemented, it could be like that, or it can be that it is evaluated when you execute the program (but not at compile time). But if I just but code that the top level of a file, when at runtime is that executed? -- /Jacob Carlborg
Re: Crystal
On 2013-02-17 20:50, JN wrote: http://delight.sourceforge.net/ There we go, thanks. -- /Jacob Carlborg
Re: D 2.062 release
On 2013-02-18 06:37, Steven Schveighoffer wrote: I agree, we need a better system. Manually edited has its faults, and the current system has its faults. We could have a section that is edited manually with some important highlights with proper full description of new features and deprecated/removed ones. Then, in addition to that we could have a link to bugzilla for the rest. -- /Jacob Carlborg
Re: D 2.062 release
On 2013-02-18 07:31, Walter Bright wrote: Since I (and Jonathan) wrote the changelog, I can attest that I cut pasted it character for character out of the bugzilla titles, and received no comments or complaints about it. I did it that way because people on the n.g. asked me to do it that way. How about a script that doesn't it automatically? Then we at least don't have to go to bugzilla. -- /Jacob Carlborg
Re: vibe.d 0.7.12 released
On 2013-02-11 20:08, FG wrote: Great project -- a flagship example of D's real world application! On 2013-02-11 19:11, Ali Çehreli wrote: same code as Python, translated to D. Of course, the solution that use vibe.d does not have Python's infamous GIL; instead, it comes with parallelism and concurrency out of the box. And you are aware of typos in your code even before running your program. ;) Running worker processes can make the GIL problem a little less of a PITA, but having the typos pointed out before running the app... is just priceless. :) I'm struggling with the temptation to move a Python website to vibe.d. What keeps me from doing that are Django templates. Not even because vibe's templates have to be recompiled each time some small markup change is introduced -- I got used to that with LaTeX ;) -- but because of Jade. It's way too far off course from HTML for my tastes. I see no reason for inventing a completely new format when all you need is templating. So let me use this opportunity to ask you: is somebody working on other template systems for vibe.d already or shall I get involved myself? I'm thinking about something similar to this, syntax-wise: http://jinja.pocoo.org/ I like Haml, it's similar to Jade but without the pipes for the plain text. What about plain HTML, like Ruby (Erb) or PHP uses. -- /Jacob Carlborg
Re: vibe.d 0.7.12 released
On 2013-02-11 22:07, FG wrote: The problem I have with those is that they are designed for HTML. What if I wanted to make an email template instead? Erb is like a Ruby preprocessor that can be used for any format. It's used for many things in Ruby on Rails: index.html.erb - Erb preprocessor, result is HTML % if foo % liasd/li % end % bar.js.coffee.erb - Erb then CoffeeScript preprocessor, result is JavaScript % if foo % bar = - console.log(asd) % end % foo.text.erb - Erb preprocessor, result is plain text % if foo % asd % end % database.yml.erb - Erb preprocessor, result is YAML development: username: %= username % password: %= password % -- /Jacob Carlborg
Re: Another opportunity for a major design win has presented itself
On 2013-02-07 21:16, Walter Bright wrote: No, I can't say who it is at this time. Sorry. But it is a huge opportunity for us. To get the design win, we need to: (a) get dynamic linking and loading to work We want to have this on all platforms but is there a platform that is prioritized for them? -- /Jacob Carlborg
Re: Another opportunity for a major design win has presented itself
On 2013-02-07 22:01, Maxim Fomin wrote: On Thursday, 7 February 2013 at 20:16:03 UTC, Walter Bright wrote: No, I can't say who it is at this time. Sorry. But it is a huge opportunity for us. This is nice. To get the design win, we need to: (a) get dynamic linking and loading to work Wasn't this realized before? By the way, last weeks there seems to be increasing dynamic linking loading buzz like it was not an issue for ages. As far as I know and if nothing has changed in the recent days shared libraries to not work, at least not on Posix. -- /Jacob Carlborg
Re: Another opportunity for a major design win has presented itself
On 2013-02-07 21:16, Walter Bright wrote: (a) get dynamic linking and loading to work I'm willing to help on this one, especially for Mac OS X. I have wanted this for quite a long time. -- /Jacob Carlborg
Re: DIP22 : Private symbol visibility
On 2013-02-01 16:08, Leandro Lucarella wrote: PS: Yes, I know there are the .di files, but even trying to use that makes thing extremely hard, because you need to parse the whole file to generate it and the difference between parsing and compiling is not that much. And then, as in C++, you have templates. In C and C++ you don't have anything to generate them, you need to write them manually. You can do that same with D. -- /Jacob Carlborg
Re: DIP22 : Private symbol visibility
On 2013-01-31 11:11, Dicebot wrote: Ugh, how can you split module into two source/object files? Naive approach will result in linker error due to multiple definition of ModuleInfo. I did not know it was possible, would have been really cool to have. I'm not 100% sure if it's possible, but it's theoretically possible. -- /Jacob Carlborg
Re: Mono-D v0.4.9.5 - Infinite analysis fix + Mixin analysis improvement
On 2013-01-30 00:28, alex wrote: Okay, I've uploaded a new version that features a basically working version. There is now a separated mixin insight and expression evaluation available. There are still many things left to do though. I'll give it a try. -- /Jacob Carlborg
Re: DIP22 : Private symbol visibility
On 2013-01-30 10:57, deadalnix wrote: I understand the risk of breakage. But . . . Not worth the breakage. Is this code supposed to work in the first place ? I mean, the private function is not marked export, the language make no guarantee it will be accessible from C. Additionally, does it make sense to prevent D from calling some piece of code, but still allow some external C code to do it ? I think it is invalid code in the first place, and just happen to work right now. case 2 is more tricky, but export isn't involved here. It's not just accessing from C code. Due to D supporting separate compilation you can have the implementation of a private method in a separate object file. -- /Jacob Carlborg
Re: DIP22 : Private symbol visibility
On 2013-01-30 17:26, deadalnix wrote: The code is in C in the example. But if you replace the C code by another D module, the exact same reasoning holds. What point are you trying to make by raising that ? It seems completely irrelevant to me. Or I didn't inferred the part of the reasoning that was implied in your post. Please make it explicit. If you have a public and a private function in the same module, it's possible to implement the two functions in two separate object files. The private function must then be available in the object file to link the program properly. -- /Jacob Carlborg
Re: Mono-D v0.4.9.5 - Infinite analysis fix + Mixin analysis improvement
On 2013-01-28 23:09, alex wrote: Yeah I just named it Expression evaluation - dunno why, just thought that it could be used in a more general way than 'only' for mixin insight. Should I do an extra input box where you could type in expressions and other things that could be evaluated? Just thinking of a prototype of an interactive D script console or so.. :) Sure, why not. -- /Jacob Carlborg
Re: Mono-D v0.4.9.5 - Infinite analysis fix + Mixin analysis improvement
On 2013-01-29 03:14, alex wrote:
On Tuesday, 29 January 2013 at 00:48:24 UTC, F i L wrote:
Meaning, imagine your screen looks like:
CODE | EXAMPLE RESULTS
|
int foo(int x, int y) | params: (2, 3) // editable
{ |
return x * y + 5 | returns: 11// not-editable
} |
|
That would simply amazing! I don't expect you to make that, lol, only
want to know if it's possible (or foreseeable) with your expression
evaluation engine. Is it?
Side-by-side? This could be your contribution then :P
I actually did watch this one video where that one guy just
edited some javascript in his uber-editor and the WebGL
animations reacted on his coding in pseudo-realtime in the
browser :D
Yeah, that was s cool. I also liked the code bubbles. Instead of
having a file as the minimum abstraction unit in the IDE/editor it was a
function/class/method.
--
/Jacob Carlborg
Re: Mono-D v0.4.9.5 - Infinite analysis fix + Mixin analysis improvement
On 2013-01-29 11:52, alex wrote: Which can be done in Eclipse by just selecting e.g. a method or class in the outline - iirc it'll just show the definition of the selected node then, nothing else. If I select an item in the outline view it will just scroll the editor view to where that item is defined. I want to be able to have three code bubbles open, side by side, showing three different methods from the same file. -- /Jacob Carlborg
Re: Mono-D v0.4.9 - Rough formatting capability
On 2013-01-29 13:34, Bruno Medeiros wrote: Ah, fair enough. Yes, that could be an approach, although I dread a bit the thought of having to interface D data to Java through a C API... it might work though if one is carefull and manages to keep the interfacing data simple enough (and leave the complex stuff in their own language realm). But to be honest, the main reason that keeps me from that approach, is that I feel I'm far more productive with Java than with D at the moment. Mostly because not of the language itself, but the excellent IDE semantic functionality, and debugger functionality, that Java has available. So yeah, kinda of a bootstrapping problem. :) Hehe, yeah, it's kind of the chicken and egg problem. -- /Jacob Carlborg
Re: Mono-D v0.4.9.5 - Infinite analysis fix + Mixin analysis improvement
On 2013-01-29 13:26, Bruno Medeiros wrote: By default, yes, but you can do what Jacob wanted with the Show Source of Selected Element Only functionality: http://help.eclipse.org/juno/index.jsp?topic=/org.eclipse.jdt.doc.user/reference/views/ref-java-editor.htm That's somewhat similar to what I had in mind. But that just removes all other code that is not selected from the editor. I want to have multiple editors or views of the same file side by side. These views don't need to be any larger than the code they're showing. -- /Jacob Carlborg
Re: Mono-D v0.4.9.5 - Infinite analysis fix + Mixin analysis improvement
On 2013-01-28 13:32, alex wrote: K..Created an extra panel, and the actual mixin evaluation is working, too. But now there are some last adjustments required to have the entire mechanism as few annoying and performance-reducing as possible. Cool, I guess it's time to give Mono-D another try. -- /Jacob Carlborg
Re: DIP22 : Private symbol visibility
On 2013-01-28 18:05, Dicebot wrote: http://wiki.dlang.org/DIP22 There are two important issues with current protection attribute design: * Senseless name clashes between private and public symbols * No way to specify internal linkage storage class This DIP addresses both of them with two decoupled proposals: * Change of private related name resolution rules * Definition of static storage class for module-scope symbols. ___ Quotes, data and link to previous discussion: http://wiki.dlang.org/Access_specifiers_and_visibility ___ I think this is the point where public discussion will do more good than my own exploration of corner cases. Please destroy and pay closest attention to compile-time reflection - I have a feeling I have missed something there. I think it looks good. What's not mentioned is .tupleof, see: http://forum.dlang.org/thread/llizpsrachdtqtshp...@forum.dlang.org?page=2#post-ke6lv8:242nn8:241:40digitalmars.com -- /Jacob Carlborg
Re: Mono-D v0.4.9.5 - Infinite analysis fix + Mixin analysis improvement
On 2013-01-27 12:27, alex wrote: Morning D folks, Implemented some new features concerning pre-compile time mixin analysis and expression evaluation: http://mono-d.alexanderbothe.com/?p=814 (Screenshot included) Nice. I'm not sure if this is what Dicebot suggested but would it be possible to implement a compile time view, like Descent had? It how showed template and string mixins are expanded. It also showed how some language features are lowered to other features, like the scope statement being lowered to try/catch/finally. This clip shows the compile time view in action: http://www.youtube.com/watch?v=oAhrFQVnsrYnoredirect=1 -- /Jacob Carlborg
Re: Mono-D v0.4.9.5 - Infinite analysis fix + Mixin analysis improvement
On 2013-01-27 13:35, alex wrote: Well, not displaying the entire module but only displaying resolved expressions. Dunno how to do this in a proper way - only via tooltips or also in an extra panel? Which would be the most useful? If it cannot show the entire module then I think a tooltip would be best suited. Btw, since I'm not that involved in D's magic I definitely haven't planned such extensive pre-compilation :D It can be extremely helpful to see how a template/string mixin is expanded when debugging. It can also be fun to see how the compiler behaves internally, i.e. scope-statements are lowered to try/catch/finally. Any D IDE has quite a lot of expectations to live up since it most certainly will be compared with Descent. -- /Jacob Carlborg
Re: Mono-D v0.4.9 - Rough formatting capability
On 2013-01-26 01:23, alex wrote: Why not wrap dmd's front-end? The problem with the DMD frontend is that it's not made to be used in on its own, like in an IDE. -- /Jacob Carlborg
Re: Mono-D v0.4.9 - Rough formatting capability
On 2013-01-25 13:01, Bruno Medeiros wrote: If I was going with that approach I likely would rather port the MonoD parser since it looks just as good, if not better, and C# would be easier to port to Java than D. But the descent.compiler experience (parser ported from DMD's parser) put me off that approach of porting from a parser in another language (although the VisualD parser might have less shortcomings than using the DMD parser since at least VisualD's parser is designed for IDE use). I want to have more control over the parser, and be able to effect my own changes in it (something tricky if you're porting - unless you give up the porting at some point, and just fork your own version and use ir from there) I didn't say anything about porting :) I was suggesting you integrate the VisualD parser without porting it. That's why I suggested the one in VisualD and not the one in Mono-D. -- /Jacob Carlborg
Re: Mono-D v0.4.9 - Rough formatting capability
On 2013-01-25 20:00, alex wrote: I already suggested Rainer to make a native/non-native interface between VisualD and D_Parser - this will probably happen via COM or so.. and I dunno anything about that technique. I just can make sure that the parser library is fully stand-alone, only depending on .net internals. Let's see :) It should provide an C interface, then it can be connected to anything. -- /Jacob Carlborg
Re: Mono-D v0.4.9 - Rough formatting capability
On 2013-01-24 14:12, Bruno Medeiros wrote: That's a lot of continuing nice work coming out from there, impressive! BTW, something I've been meaning to ask. I see that in Mono-D you've developed a hand-written D parser. How long did it take you to write that? Did you test it extensively or not so much? I'm embarking on that same task in Java, for DDT, and wondering how long it will take to build a quality parser. So far, it doesn't seem writing the actual parser will take that long, but writing extensive tests for it is seeming exceedingly complicated (or just lengthy and time-consuming). I'm usually a big proponent of TDD, but when writing a lot of tests starts to take a lot of time compared to the code being tested (in this case, maybe 1.5 times the effort/time of the code being tested), I'm not so certain it's the right call to spend so much time writing tests... How about reusing the one in VisualD, it's written in D? Sure it's a bit more work since it's not written in a Java compatible language but it might be worth it. -- /Jacob Carlborg
Re: add -gx to add stack smash code
On 2013-01-24 06:32, Walter Bright wrote: https://github.com/D-Programming-Language/dmd/pull/1542 I haven't noticed any other compiler with this feature. What it does is upon function exit, it 'smashes' all the memory used for local variables. The idea is to flush out any dependencies on the now-out-of-scope stack frame. Throw this switch when you are experiencing bizarre crashes that come and go - it may help find the root of the problem by causing it to fail sooner and more predictably. It may also be handy if, for crypto code, you don't want to leave passwords around in memory, though I'd be more proactive about that than relying on this. You've started to use pull requests for DMD, nice. Does this take into account delegates that are closures? -- /Jacob Carlborg
Re: Mono-D v0.4.7 - Optlink output analysis / Symbol name demangling
On 2013-01-13 02:10, alex wrote: https://github.com/aBothe/Mono-D/issues Since I didn't know what the exact expected functionality was I wanted to discuss here first. Uses xterm (at least on linux) to display stuff in an external console. Definitely wasn't my idea. There probably is the possibility to redirect stin/out/err streams into some kind of internal log or so - but then probably the question will rise up whether one can pass input to stdin. Haven't tried it out yet - yes, yet - though Mono-D exists 1.5 years. I see, so it's a problem with MonoDevelop. But I don't get any output, is that also an issue with MonoDevelop? That's where D magic vs. my programming ability comes into the game. I can't and I won't guarantee that both works in all cases (of course not) - all I can do is to make it run in as many cases as possible. There might be couple of strange or uncommon (yes, even common) situations where I haven't thought that these could ever occur. In such cases, please note them down somewhere and tell me what's not working as expected in particular. I'll try and do that. Did you really expect I had finished implementing CTFE so all mixins etc could be resolved? Absolutely not. That's way I said I don't use any of these language constructs. Completion-related issues may get straight to https://github.com/aBothe/D_Parser please. Will do. I've reported a couple of issues now. -- /Jacob Carlborg
Re: Mono-D v0.4.7 - Optlink output analysis / Symbol name demangling
On 2013-01-12 15:28, alex wrote: Hi everyone, Just released a new version - For info, see http://mono-d.alexanderbothe.com I just tried Mono-D again and I'm having some problems. * Running an application When I try to run a simple Hello World application it opens a new empty terminal, nothing is printed. I also though that MonoDevelop would run the application and display its output in an internal console view. * Go to definition and autocompletion I have no idea how good these features are supposed to be but to me they work very inconsistently. I have one project where go to definition basically only works for what's in the same file. I have another project where it seems to work fine, mostly. There is no fancy mixin or template code in these projects. A few questions: * Does Mono-D do autocompletion or go to definition from external files like files from Phobos and druntime? * Can Mono-D resolve type inference? I'm using Mac OS X. -- /Jacob Carlborg
Re: Shared Libraries [was Re: D 1.076 and 2.061 release]
On 2013-01-10 06:18, Walter Bright wrote: On 1/9/2013 11:02 AM, Jacob Carlborg wrote: As I said, I don't know assembly but here's the output: Good time to learn it! Do you have any good books to recommend for this? I will most likely not have time to learn assembly now. I'm busy with other things and I think I could spend my time better by contributing with other D related things. Also you said: No prob. I'll be happy to make compiler mods as necessary, once the exact problems are identified. http://forum.dlang.org/thread/kbvsgo$1po3$1...@digitalmars.com?page=26#post-kcdvjh:242a1f:241:40digitalmars.com -- /Jacob Carlborg
Re: Shared Libraries [was Re: D 1.076 and 2.061 release]
On 2013-01-10 21:13, Walter Bright wrote: No. But a reasonable way is to just get the instruction set reference from Intel, and single step some D code in assembler mode in the debugger and go instruction by instruction. I see, thanks. I think you'll be pleasantly surprised at how knowing assembler will improve your high level coding abilities. Yeah, that's one thing I've learned by reading the newsgroups here. -- /Jacob Carlborg
Re: Shared Libraries [was Re: D 1.076 and 2.061 release]
On 2013-01-11 05:22, deadalnix wrote: I have to concurs with Walter here. Knowing assembly language is a great way to improve you knowledge of programming in general. This is way easier than what most dev think. I personally know assembly for ARM and x86, and it is clearly helpful. I have no doubt that it can be useful and helpful. The time to learn it just competes with so much else. -- /Jacob Carlborg
Re: Shared Libraries [was Re: D 1.076 and 2.061 release]
On 2013-01-07 09:04, Walter Bright wrote:
Please nail down what is necessary first. (BTW, I don't know how the
compiler can tell what image an address comes from. Remember, shared
libraries are loaded at runtime, not compile time.)
I've done some investigation. Currently DMD inserts a call to the
__tls_get_addr function when accessing a TLS variable. This is
implemented in druntime.
In Mac OS X 10.7 it works similar but instead of inserting a call to
__tls_get_addr there's a struct looking like this (written in D) :
struct TLVDescriptor
{
void* function (TLVDescriptor*) thunk;
size_t key;
size_t offset;
}
The dynamic linker will iterate all loaded images and extract the
section containing the TLS data. I guess this section consists of a list
of TLVDescriptor*. The dynamic linker will set the thunk to a function
tlv_get_addrs, implemented in assembly in the dynamic linker. It will
set the key to a key created by pthread_key_create. It will also map
the image with this key. This key is same for all TLVDescriptor of a
given image.
Instead of calling __tls_get_addr I think that the compiler will need
to call the thunk passing in the TLVDescriptor itself to the thunk.
The tlv_get_addrs function will then extract the key and from that key
it can get the image the address belongs to.
Does that make any sens? Is that something the DMD could do, that is
call the thunk instead of __tls_get_addr.?
--
/Jacob Carlborg
Re: Shared Libraries [was Re: D 1.076 and 2.061 release]
On 2013-01-09 11:26, Jacob Carlborg wrote: I think it sounds like that but I don't know. I'm just trying to figure out how TLS is implemented on Mac OS X 10.7+. Also, there's nothing else that calls this tlv_get_addr function or the thunk so I'm guessing it's the compiler that calls it. -- /Jacob Carlborg
Re: Shared Libraries [was Re: D 1.076 and 2.061 release]
On 2013-01-09 11:00, deadalnix wrote: Isn't it horrible performancewise ? I think it sounds like that but I don't know. I'm just trying to figure out how TLS is implemented on Mac OS X 10.7+. -- /Jacob Carlborg
Re: Shared Libraries [was Re: D 1.076 and 2.061 release]
On 2013-01-09 11:38, Walter Bright wrote:
Watcha do is something like this:
__thread int x;
int foo() { return x; }
Compile, disassemble, and look at the code generated and the fixup
records. Then there's no need to guess :-)
Sure, I've already done that. I compared one version using __thread
and one version without __thread. I do see the differences of the
disassembly but that doesn't help me, I don't know assembly. The only
interesting I could find is that it does perform a call, the version
with __thread.
I don't have access to a machine running Lion+ but you could take a look
at this:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52268
That's a bugzilla issue for the same thing for GCC. The comments contain
some disassembly of uses of __thread.
--
/Jacob Carlborg
Re: Shared Libraries [was Re: D 1.076 and 2.061 release]
On 2013-01-09 19:53, John Colvin wrote: Surely __thread is redundant there, seeing as x will be TLS by default? We're talking C here and it's not default in C. -- /Jacob Carlborg
Re: Shared Libraries [was Re: D 1.076 and 2.061 release]
On 2013-01-09 11:38, Walter Bright wrote:
Watcha do is something like this:
__thread int x;
int foo() { return x; }
Compile, disassemble, and look at the code generated and the fixup
records. Then there's no need to guess :-)
As I said, I don't know assembly but here's the output:
Original code: http://pastebin.com/UKb6etWD
Disassembly with TLS: http://pastebin.com/nkdnE9w6
Disassembly without TLS: http://pastebin.com/vuvEBWWH
Object dump with TLS: http://pastebin.com/PqpPw56a
Object dump without TLS: http://pastebin.com/ki6atzEm
--
/Jacob Carlborg
Re: D 1.076 and 2.061 release
On 2013-01-08 09:57, Walter Bright wrote: The moment D1 was stabilized, work began on D2. It was always understood that D2 was the future, and D1 was the stable version. Supporting it for 6 years is a pretty long time in the software business. At some point, you'll need to make a decision: 1. move to D2 2. merge things from D2 into the D1 you've forked 3. buy a support contract from Digital Mars or from any of the many other competent people in the community to help you with D1 4. There's also Amber now which seems to be basically the same as D1 http://forum.dlang.org/thread/zflwhizhppbdqfioz...@forum.dlang.org -- /Jacob Carlborg
Re: Shared Libraries [was Re: D 1.076 and 2.061 release]
On 2013-01-08 13:52, Russel Winder wrote: On Tue, 2013-01-08 at 08:27 +0100, Jacob Carlborg wrote: Interesting, I was told not to try upgrading to Lion, but to stay with Snow Leopard. I just did. MacBook2.1, Core 2 Duo, 2GB. I think mine is from late 2006. This has a 64-bit processor, but 32-bit boot PROM, which means OS X will only run in 32-bit mode. This causes great pain since OS and processor report different states of being, leading to real pain building stuff. I haven't noticed any problems. -- /Jacob Carlborg
Re: Shared Libraries [was Re: D 1.076 and 2.061 release]
On 2013-01-08 14:05, Russel Winder wrote: Looks like Apple are turning Snow Leopard 10.6 into their equivalent of XP: http://www.computerworld.com/s/article/9233244/OS_X_Snow_Leopard_shows_signs_of_becoming_Apple_s_XP From the list on http://www.apple.com/osx/how-to-upgrade/ I cannot upgrade to Mountain Lion 10.8, and Apple provide no way of upgrading to Lion 10.7. Thus I am forced to be Snow Leopard 10.6 for ever more. They don't sell USB sticks anymore? -- /Jacob Carlborg
Re: Shared Libraries [was Re: D 1.076 and 2.061 release]
On 2013-01-08 14:05, Russel Winder wrote: Looks like Apple are turning Snow Leopard 10.6 into their equivalent of XP: http://www.computerworld.com/s/article/9233244/OS_X_Snow_Leopard_shows_signs_of_becoming_Apple_s_XP From the list on http://www.apple.com/osx/how-to-upgrade/ I cannot upgrade to Mountain Lion 10.8, and Apple provide no way of upgrading to Lion 10.7. Thus I am forced to be Snow Leopard 10.6 for ever more. Actually, I have the installation for Lion left on my hard drive. -- /Jacob Carlborg
Re: Shared Libraries [was Re: D 1.076 and 2.061 release]
On 2013-01-08 21:49, Walter Bright wrote: So it won't run any 64 bit software? It can run 64bit software just fine. Mac OS X has been able to do that for a long time. 10.6 was the first version the kernel tries to run in 64bit mode (depends on the computer). Just because the kernel doesn't run in 64bit doesn't mean that the rest of the software can't run in 64bit. For at least a couple releases now, dmd for OS X has only included the 64 bit binaries for dmd. Not a single person has noticed (at least nobody has commented on it). We do build and test the OS X 32 bit dmd binaries, but left them off of the install package. There is no problem. -- /Jacob Carlborg
Re: Shared Libraries [was Re: D 1.076 and 2.061 release]
On 2013-01-07 13:41, David Nadlinger wrote: Yes, it is not supported by linker and dyld versions shipping with OS X 10.7. This is also the reason why LDC 2 only supports OS X 10.7+, as LLVM does not implement a workaround for older versions (although implementing one up to the point where it is good enough for D should be doable without too much effort). I've looked a bit at this and if we want to emulate TLS and support dynamic libraries on Mac OS X 10.6 I think we basically need to do what the dynamic linker does on 10.7. -- /Jacob Carlborg
Re: Shared Libraries [was Re: D 1.076 and 2.061 release]
On 2013-01-07 01:25, Walter Bright wrote: Sean would be the main one, but really anyone who is willing to get down and dirty with threads and such can do it. Martin Nowak has already started on this, it seems he know what he's doing: https://github.com/dawgfoto/druntime/tree/SharedRuntime -- /Jacob Carlborg
Re: D 1.076 and 2.061 release
On 2013-01-07 01:36, Walter Bright wrote: The thing is, roadmaps are a lot like planning for a war. The moment the first shot is fired, all the plans go out the window. What we need to get done next is a constantly evolving situation, based on: On occasion developer are asking what they can work on and then we don't have a roadmap to point to. -- /Jacob Carlborg
Re: Shared Libraries [was Re: D 1.076 and 2.061 release]
On 2013-01-07 11:14, Robert Clipsham wrote: Note that this no longer appears to be the case, at least with clang (OS X 10.7.5): Mac OS X Lion (10.7) got support for TLS. But that means that the whole TLS needs to be redone in the compiler (output data to correct segments and similar) and in the runtime. The compiler would also need to be able to fallback to emulating as it currently does or we will loose the support for Mac OS X 10.6. Alternatively it might be possible to run the real TLS on Mac OS X 10.6 but then we would need to implement some parts of the dynamic linker into the D runtime. -- /Jacob Carlborg
Re: Shared Libraries [was Re: D 1.076 and 2.061 release]
On 2013-01-07 09:04, Walter Bright wrote: Please nail down what is necessary first. (BTW, I don't know how the compiler can tell what image an address comes from. Remember, shared libraries are loaded at runtime, not compile time.) I'll try and do that. -- /Jacob Carlborg
Re: D 1.076 and 2.061 release
On 2013-01-07 19:29, Andrei Alexandrescu wrote: It's less structured than a roadmap but maybe that's what would make it tenable! It would be like a roadmap without the timeline. That's a lot better than nothing. -- /Jacob Carlborg
Re: Shared Libraries [was Re: D 1.076 and 2.061 release]
On 2013-01-07 20:54, Walter Bright wrote: It's pretty clear where we'll be going with this. We'll be abandoning OS X versions older than 10.7. Would it be a bad idea and do what the dynamic linker does in the druntime to support TLS? This would make it work on Mac OS X 10.6. I don't know enough about the Mac ecosystem to know when we can pull the plug on that. Me neither. Mac OS X 10.6 was released August 28, 2009. There have been two major releases since then. -- /Jacob Carlborg
Re: Shared Libraries [was Re: D 1.076 and 2.061 release]
On 2013-01-07 21:30, David Nadlinger wrote: I don't know the current relative market share of the different OS X versions on top of my head either, but as we were getting a couple of bug reports from people who had tried to use LDC 2 on 10.6 (before we figured out that LLVM doesn't emulate TLS there), I guess it's too soon to drop support for it still. However, when finally somebody finds the time to implement shared library support in the runtime, the situation might have already changed anyway. In general Apple tries to push you to have always have the latest software. There are very few reasons to not have the latest OS, they are pretty darn cheap. -- /Jacob Carlborg
Re: D 1.076 and 2.061 release
On 2013-01-06 05:19, Pierre Rouleau wrote: I know. What I'm trying to see is what is the development *plan* for D2? Something that would identify the future features to be implemented and the planned targets/milestones for them. I would assume that I am not alone in watching the D language evolution, would like to get people to start using it at my work place, and would like to know what the plan is be so we can better convince other people to invest time into it. I've requested that for years, still nothing. Well that only thing I've seen is that the change log used to say Under Construction: Shared libraries for Linux. Still does for D1. -- /Jacob Carlborg
Re: Runtime code reloading in D, part 1
On 2013-01-06 11:37, Benjamin Thaut wrote: I wouldn't say its moving away from it. Some recent changes to druntime have made it significantly less leaking. But on the other hand a API design like toString() which pretty much does leak in almost all cases don't exactly help a GC free D. In Summary it feels to me that GC free D is not important to the community or the active contributors. The design of toString() has been up for debate a couple of times. Many are not happy with the design. -- /Jacob Carlborg
Re: Runtime code reloading in D, part 1
On 2013-01-06 11:30, Benjamin Thaut wrote: Yes I know flectioned. But I did not require that much RTTI information. No I'M not manually triggering the code for generating the RTTI. As mentioned in the article it is done via the RTInfo template inside object_.d / object.di which is automatically instanciated for each type used during compilation. Ah, so you modified the existing RTInfo? I didn't know that existed. -- /Jacob Carlborg
Re: Shared Libraries [was Re: D 1.076 and 2.061 release]
On 2013-01-06 12:27, Russel Winder wrote: I know that the Go folk are of the view that shared libraries are an abomination and all should be expunged from the universe; all Go executables are statically linked. Of course Linux, OS X, Solaris and AIX depend on shared libraries, but maybe Google think they can change the world? I'm pretty sure that they're linking with the dynamic libraries when linking with systems libraries. As you say, they don't have much of a choice. I guess they don't create new dynamic libraries with Go. If D is to compete with C, C++ and JVM-based languages then it has to have a position on shared libraries other than we think it might be a good idea, but no-one has bothered to do anything about it to date. Either is is a good idea or it isn't. If it is a good idea then shared libraries should be in 2.062. If it isn't then a clear statement of won't fix and D is a static compile only language, like Go is needed. I completely agree. We _need_ dynamic libraries. But the problem is that someone just have to do it and Walter doesn't seem to be in a rush to implement it. Of course then the issue is How to link to shared libraries?. Go has some difficulties here but the put a shim in place to deal with it. What would be the issue of linking with dynamic libraries? We can already link with C dynamic libraries without any problem. -- /Jacob Carlborg
Re: Runtime code reloading in D, part 1
On 2013-01-06 13:19, Benjamin Thaut wrote: Here is the full implementation if you are interested: https://github.com/Ingrater/druntime/blob/master/src/rtti.d Thanks. Is that possible to do without having to modify the runtime? -- /Jacob Carlborg
Re: Shared Libraries [was Re: D 1.076 and 2.061 release]
On 2013-01-06 13:20, Russel Winder wrote: Is Walter the only person who can implement this? I cannot commit to doing anything on this in the foreseeable short-, to medium-term future, but is there anyone who can? No, absolutely not. But no one has been willing to do it yet. Martin Nowak seems to be closest to have something: https://github.com/dawgfoto/druntime/tree/SharedRuntime I have tried myself a couple of times but there has always been some issue with the compiler that needs to be fixed or implemented. I have never been able to figure out how to do that. For example, on Mac OS X where DMD implements its own TLS the compiler will most likely need to change somewhat. https://github.com/D-Programming-Language/druntime/blob/master/src/core/thread.d#L4549 In the above code we need to have access to which image that address (p) to the belongs to. For the Go folks, it is all about issues with garbage collection and thread management, they need to perform contortions to deal with C and C ++ codes. I recollect it is to do with the way Go handles execution stacks. I see. -- /Jacob Carlborg
Re: D 1.076 and 2.061 release
On 2013-01-06 16:20, Pierre Rouleau wrote: Is there a file somewhere that lists all requested features, under development features? Or the various mailing lists the only source of information? There is some information at the wiki, the DIP's. -- /Jacob Carlborg
Re: Shared Libraries [was Re: D 1.076 and 2.061 release]
On 2013-01-07 00:19, Walter Bright wrote: I have fixed every single PIC implementation compiler problem that has been brought to my attention. If there are others, I am not aware of them. Please let me know the bugzilla issue numbers for any I have missed. I know you have. The problem is that there might be necessary to do some changes to the compiler. That doesn't mean there is a bug. DMD implements its own TLS on OS X because the OS X C compiler says not implemented when you try to create TLS variables. I had no other option. Yeah, I know. I'm not complaining. The OS X TLS implementation is all done in druntime. Not 100%. I'm thinking of the __tls_get_addr function which the compiler calls: https://github.com/D-Programming-Language/druntime/blob/master/src/core/thread.d#L4549 That function needs to know which image the given address belongs to. I think that the compiler needs to supply that, in addition to the address, but I'm not sure. If it does it requires a change in the compiler. I can add this to bugzilla. Nevertheless, this does not impact Linux nor FreeBSD. Mac OS X is my main platform. It's natural that I try to get it to work there first. -- /Jacob Carlborg
Re: Runtime code reloading in D, part 1
On 2012-12-30 13:32, Benjamin Thaut wrote: An article about runtime code reloading in the context of game developement. A topic I'm currently working on in my spare time. I hope it holds some valuable information for everyone working with D. http://3d.benjamin-thaut.de/?p=25 This looks very cool. Question, are you manually triggering the code for generating the RTTI? BTW, have you seen this old project implementing runtime reflection: http://flectioned.kuehne.cn/ -- /Jacob Carlborg
Re: D 1.076 and 2.061 release
On 2013-01-03 22:31, Pierre Rouleau wrote:
FWIW, you can see some info here:
http://forum.dlang.org/thread/k7afq6$2832$1...@digitalmars.com
Funny thing, the syntax in the original post by Walter was deprecated
from the beginning. The correct syntax is:
@(4) int a;
Or
struct Foo
{
int b;
}
@Foo(3) int c;
--
/Jacob Carlborg
Re: D 1.076 and 2.061 release
On 2013-01-02 00:46, Walter Bright wrote: The big news is Win64 is now supported (in alpha). http://www.digitalmars.com/d/download.html D 1.076 changelog: http://www.digitalmars.com/d/1.0/changelog.html A couple issues: 1. the dlang.org isn't updated yet. 2. the OS X package hasn't been built yet (problems with the package script). I hope to get these resolved shortly. In the meantime, enjoy and have a Happy D Year! I create a pull request with docs for UDA's: https://github.com/D-Programming-Language/d-programming-language.org/pull/231 -- /Jacob Carlborg
Re: D 1.076 and 2.061 release
On 2013-01-04 15:26, Philippe Sigaud wrote: Yeah, I read that when it happened. But I don't want to read entire threads months afterwards to see how a feature work. And, honestly: *no-one* coming from outside this discussion group can understand that 2.061 brings UDA, or what UDA are. I agree. I'll start a new thread on this. This seems to be a major new feature and it appears nowhere! I create a pull request with some documentation: https://github.com/D-Programming-Language/d-programming-language.org/pull/231 -- /Jacob Carlborg
Re: D 1.076 and 2.061 release
On 2013-01-04 15:27, Philippe Sigaud wrote: Nice move! Too bad I get a pink unicorn from this one. Github is becoming stranger and stranger :) Works for me. Try this one: https://github.com/jacob-carlborg/d-programming-language.org/commit/bddbdf18353203ba12d8e0e44391e8b6a031b91a -- /Jacob Carlborg
Re: D 1.076 and 2.061 release
On 2013-01-04 16:32, Philippe Sigaud wrote: Yeah, that works, thanks! Now for some reading. This might be easier to read. I rendered the DDOC to HTML: https://dl.dropbox.com/u/18386187/attribute.html#uda There's also documentation for the Traits section but nothing which isn't available on the Attribute section. -- /Jacob Carlborg
Re: D 1.076 and 2.061 release
On 2013-01-02 22:19, Walter Bright wrote: Having backups doesn't work so good when the versions and settings change with a new OS. I mean, before you upgrade the OS you make sure you have everything backed up. Then if the installation trashes everything you can at least rollback to the previous state. -- /Jacob Carlborg
Re: vibe.d 0.7.10 released
On 2013-01-03 11:54, Russel Winder wrote: May I suggest you need to do some marketing against: node.js vert.x goweb revel Play! Django Grails Ruby on Rails Flask Sinatra Ratpack Why would anyone want to use vibe.d in preference to any of the above? Is there a lightning talk I can do at ACCU, PyCon UK, Gr8Conf, GGX, EuroPython, etc. to show that the pet Web framework/Web toolkit of the language of the conference is rubbish in comparison to that of D? One of the great things about Ruby on Rails is that it's got a plugin for everything (and a bit more). Oh, and I really like the assets pipeline. It compiles SASS, CoffeeScript and similar languages to CSS and JavaScript. It's also possible to pipe it through Ruby first. In production environment it merges all separate CSS/JavaScript files into one and minifies it. It also adds a unique hash to the end of the filename to avoid conflicts with cached files. -- /Jacob Carlborg
Re: D 1.076 and 2.061 release
On 2013-01-02 22:19, Walter Bright wrote: Having backups doesn't work so good when the versions and settings change with a new OS. I can also add that the latest upgrades I have performed I cloned the hard drive containing the OS. Then I perform the upgrade on the clone, if everything works ok I either run the clone instead or does the same on the original disk. -- /Jacob Carlborg
Re: Managing email [ was Re: D 1.076 and 2.061 release ]
On 2013-01-03 19:53, Russel Winder wrote: On Thu, 2013-01-03 at 10:26 -0800, Walter Bright wrote: […] 1. I control the backups I run my own SMTP and IMAP server, including it's backing up. I like control! Next step: becoming your own ISP ? -- /Jacob Carlborg
Re: D 1.076 and 2.061 release
On 2013-01-02 00:46, Walter Bright wrote: 2. the OS X package hasn't been built yet (problems with the package script). What isn't working? Is there something I can do to help? -- /Jacob Carlborg
Re: D 1.076 and 2.061 release
On 2013-01-02 12:55, bearophile wrote: Jonathan M Davis: And how is that any different from any other release? How much time used to pass between two adjacent releases, in past? Bye, bearophile Around a month, perhaps. -- /Jacob Carlborg
Re: D 1.076 and 2.061 release
On 2013-01-02 00:46, Walter Bright wrote: 2. the OS X package hasn't been built yet (problems with the package script). I think this will fix the problem: https://github.com/D-Programming-Language/installer/pull/9 I don't know if this is the problem you encountered but: PackageMaker is apparently not included with Xcode anymore. It's not included in the auxiliary package which can be downloaded here: https://developer.apple.com/downloads/index.action The script now assumes PackageMaker is installed either in /Applications/PackageMaker.app/Contents/MacOS/PackageMaker or, as before, /Developer/usr/bin/packagemaker. -- /Jacob Carlborg
Re: D 1.076 and 2.061 release
On 2013-01-02 20:09, Russel Winder wrote: I have the opposite experience, Apple hardware seems incapable of upgrading operating systems. Their policy seems to be you want a new operating system, then buy a new piece of hardware from the store. I've been updating a couple of Macs from 10.6 through 10.7 to 10.8 without any problems. I'm still using an old Macbook that was shipped with 10.4, it's running 10.7 now. Although that has had a couple of reinstalls. -- /Jacob Carlborg
Re: D 1.076 and 2.061 release
On 2013-01-02 19:51, Walter Bright wrote: I've been avoiding upgrading Ubuntu, because the last time I did that the installer trashed everything. Lost a day on that one. That's what backups are for :) -- /Jacob Carlborg
Re: D 1.076 and 2.061 release
On 2013-01-02 18:53, Walter Bright wrote: The various packages are all built on Ubuntu. The OS X one failed because it couldn't find ruby, and ruby does not work on Ubuntu (at least my version of Ubuntu - there is no ruby package for it). Looks like my mistake is I should have run it on OS X. Yeah, that's a requirement. Andrei has ported the Ruby script to shell script and created a pull request: https://github.com/D-Programming-Language/installer/pull/10 -- /Jacob Carlborg
Re: D 1.076 and 2.061 release
On 2013-01-02 21:37, Walter Bright wrote: Windows has gotten better in this regard, that is true. But it's still bizarre that, with Thunderbird, you can export/import the address book, but not the mail database. A welcome improvement would be to have a button to export/import the whole farkin' thing. Instead, when I installed TB on my laptop, I had to open the account settings on my desktop, and screen by screen, manually copy the data into my laptop TB install. A long and tedious and error-prone process, as there are endless screens and config settings. Copying the thunderbird profile directory should do the trick: http://kb.mozillazine.org/Profile_folder_-_Thunderbird I've created a symlink for the newsgroups messages pointing to dropbox to get synchronization. -- /Jacob Carlborg
Re: Amber
On 2012-12-21 19:02, Lars Ivar Igesund wrote: Dear D community, I've been urged by many others to post about Amber here. It is a programming language being derived from D1, with a compiler written using D1 and Tango, with LLVM and C backends. The quality of code and documention is alpha (or pre-alpha). A bit late but: It looks basically just like D1 with some additional features and some cleanup of the language. Which is kind of nice. There are several new features in D2 I really like and some that I don't like that much. The guard statement looks nice but is there any real difference compared to scope together with Object.dispose? I would really like to see some more information about the new features, like annotations. I think it's good to see that some of the developers from the old Tango days are still involved with D (kind of). At the same time I think it's sad to see that the community is still divided. Now D2 in one corner and D1/Amber in the other. I understand why you're doing this. I'm feeling the same way, quite often, about how D and the community is run Personally I've moved almost all of my projects to D2. I'm still using Tango, kudos to SiegeLord. These days I'm trying to be less political and more practical. I'm using what works and what I think works best. If I need XML I'm using Tango, if I need regular expression I'm using Phobos. -- /Jacob Carlborg
Re: Getting ready for 2.061
On 2012-12-27 00:09, Brad Roberts wrote: I haven't done a survey in a while, but all of the ones I've looked at have lacked at least one of the features I've wanted to have. 1) multi-platform 2) great integration with github and pull requests 3) ability to pull multiple repositories as a coordinated whole and likely more, those are just off the cuff. Ok, I see. -- /Jacob Carlborg
Re: Getting ready for 2.061
On 2012-12-25 20:53, Brad Roberts wrote: More hardware would be nice, but isnt a blocker for additional branch testing, software is. Working on it over the holidays. Have you considered using any existing software for continues integration server? We're using CruiseControl (the Ruby version) at work. It's simple and easy to setup and does what we need it to do. -- /Jacob Carlborg
Re: Amber
On 2012-12-25 05:22, Kelly wrote: No, Amber is not backwards compatible with D1. That is not it's purpose. It is probably close enough to 'fairly easily' convert D1 code (ie. converting Tango hasn't been a huge ordeal). I thought so, it looks pretty compatible. -- /Jacob Carlborg
Re: Amber
On 2012-12-25 04:06, Walter Bright wrote: I don't particularly like inner classes (I find them confusing), but they were added specifically to support DWT and make conversions from existing Java code easier. I'm grateful for that, thank you. -- /Jacob Carlborg
Re: Getting ready for 2.061
On 2012-12-23 20:06, Don wrote: IMHO, the big issue is, and has always been, what does the autotester test? It makes most sense to me to have all new fixes for _anything_ going into the development branch, and tests on the release branch to exist solely for regression testing just in case. It makes no sense to me to have pull testing against multiple branches. Preferably we should have the autotester running on all branches. It would be nice if the autotester could automatically start testing new branches as soon as they are pushed upstream. Now I understand that we might not have enough computers to do that. -- /Jacob Carlborg
Re: Getting ready for 2.061
On 2012-12-24 22:38, John Colvin wrote: If people aren't fussy about the EULA (which is apparently not valid in the EU anyway) then I could probably set up os x on a machine at university that could be left on indefinitely as a test machine. I wouldn't be able to do anything on that until mid-january though. I think they are. It's been talked on these newsgroups before. -- /Jacob Carlborg
Re: ICE 0.1: a moddable shoot-em-up in D
On 2012-12-21 14:13, Kiith-Sa wrote: This shouldn't happen as I don't even use that extension. It's possible that it's a bug in ICE's (outdated) copy of Derelict2. I updated Derelict2 now. Can you try pulling the changes? I'll give it a try. -- /Jacob Carlborg
Re: Amber
On 2012-12-21 19:02, Lars Ivar Igesund wrote: Dear D community, I've been urged by many others to post about Amber here. It is a programming language being derived from D1, with a compiler written using D1 and Tango, with LLVM and C backends. The quality of code and documention is alpha (or pre-alpha). Project page: https://bitbucket.org/larsivi/amber Background: http://www.dsource.org/projects/tango/forums/topic/920 Interesting, I haven't read all links yet but interesting. -- /Jacob Carlborg
Re: ICE 0.1: a moddable shoot-em-up in D
On 2012-12-20 19:41, Kiith-Sa wrote: This is the first release of ICE, a small game project I'm working on at the university. ICE is a vertical shoot-em-up created with moddability in mind. Its gameplay resembles games like Tyrian and Raptor: Call of the Shadows. Cool, but where is the Mac OS X binary :) -- /Jacob Carlborg
Re: ICE 0.1: a moddable shoot-em-up in D
On 2012-12-20 19:41, Kiith-Sa wrote: This is the first release of ICE, a small game project I'm working on at the university. ICE is a vertical shoot-em-up created with moddability in mind. Its gameplay resembles games like Tyrian and Raptor: Call of the Shadows. I've compiled the game on Mac OS X now and get the following runtime error: Failed to construct a video.sdlglvideodriver.SDLGLVideoDriver: Could not load OpenGL: Failed to load symbol glMatrixIndexPointerARB from shared library ../Frameworks/OpenGL.framework/OpenGL Perhaps you need to install new graphics drivers? Segmentation fault This is on a computer using Mac OS X 10.6, I'll try later on a Mac OS X 10.8 computer. Fork: https://github.com/jacob-carlborg/ICE/tree/osx -- /Jacob Carlborg
Re: Awesomium D wrappers/bindings
On 2012-12-14 13:52, evilrat wrote: just because when i tried debug simple program in xcode it was really pain and suffering, the whole OS X for D coding is painful :( GDB shipped with Xcode is way to old, IIRC. -- /Jacob Carlborg
