Re: Gumbo-d - D binding for Gumbo HTML 5 Parser
Look like binding have some issues. I am getting next error, after inducing: import gumbo.node, gumbo.parse; to my App Compiling using dmd... Linking... OPTLINK (R) for Win32 Release 8.00.15 Copyright (C) Digital Mars 1989-2013 All rights reserved. http://www.digitalmars.com/ctg/optlink.html C:\Users\Dima\AppData\Roaming\dub\packages\gumbo-d-0.2.2\gumbo-d.lib(parse) Error 42: Symbol Undefined _gumbo_destroy_output C:\Users\Dima\AppData\Roaming\dub\packages\gumbo-d-0.2.2\gumbo-d.lib(parse) Error 42: Symbol Undefined _gumbo_parse --- errorlevel 2 FAIL .dub\build\application-debug-windows-x86-dmd_2066-E9FCE136882C663918FD5E784 D7D2C14\ seismodownloader executable Error executing command run: dmd failed with exit code 2.
Re: Sargon component library now on Dub
On Sunday, 14 December 2014 at 03:26:56 UTC, Walter Bright wrote: http://code.dlang.org/packages/sargon These two modules failed to generate much interest in incorporating them into Phobos, but I'm still rather proud of them :-) Here they are: ◦sargon.lz77 - algorithms to compress and expand with LZ77 compression algorithm ◦sargon.halffloat - IEEE 754 half-precision binary floating point format binary16 I'll be adding more in the future. how about you take the time to add a complete set of window headers before more people loose customers or their reputation?
Re: Travis-CI support for D
On 2014-12-13 18:22, Ellery Newcomer wrote: I'm a noob when it comes to travis, so it isn't readily apparent to me, but given this, would travis support a build that installs a d compiler and also some version of python? You can basically install whatever you want. Travis supports various languages, but that mostly means what is installed by default or installed automatically. -- /Jacob Carlborg
Re: Travis-CI support for D
On 12/14/2014 01:42 AM, Rikki Cattermole wrote: And anyway, it forces us to have good infrastructure going for automated releases. We already have that, I build that in Jan 2014.
Re: Travis-CI support for D
On 12/13/2014 06:22 PM, Ellery Newcomer wrote: On 12/10/2014 08:50 PM, Martin Nowak wrote: Glad to announce that D support on Travis-CI was launched today. I'm a noob when it comes to travis, so it isn't readily apparent to me, but given this, would travis support a build that installs a d compiler and also some version of python? Read the docs, it cleary answers your questions. AFAIK a version of Python is preinstalled and yes this installs the D compiler you specify and dub. http://docs.travis-ci.com/
Re: Sargon component library now on Dub
On Sunday, 14 December 2014 at 13:31:57 UTC, disapoint wrote: On Sunday, 14 December 2014 at 03:26:56 UTC, Walter Bright wrote: http://code.dlang.org/packages/sargon These two modules failed to generate much interest in incorporating them into Phobos, but I'm still rather proud of them :-) Here they are: ◦sargon.lz77 - algorithms to compress and expand with LZ77 compression algorithm ◦sargon.halffloat - IEEE 754 half-precision binary floating point format binary16 I'll be adding more in the future. how about you take the time to add a complete set of window headers before more people loose customers or their reputation? Everything is in the lib file... it takes 30 second to copy and convert the import header from MSDN. I mean: your attack is not relevant. By the way additional imports could be added by PR by anyone tough I'm not sure if the DM team accept 3rd party PR (?).
Re: Sargon component library now on Dub
On 12/14/14, Walter Bright via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: http://code.dlang.org/packages/sargon These two modules failed to generate much interest in incorporating them into Phobos, but I'm still rather proud of them :-) Very cool that you decided to do this! code.dlang.org has become a real thing really fast, I love that it has grown so much. I'll be adding more in the future. Sweet, looking forward to it!
Re: Travis-CI support for D
On 12/10/2014 08:50 PM, Martin Nowak wrote: Glad to announce that D support on Travis-CI was launched today. http://blog.travis-ci.com/2014-12-10-community-driven-language-support-comes-to-travis-ci/ trying it out with pyd, and I'm getting ImportError: libphobos2.so.0.66: cannot open shared object file: No such file or directory are shared libraries supported?
Re: Travis-CI support for D
On 15/12/2014 5:03 a.m., Martin Nowak wrote: On 12/14/2014 01:42 AM, Rikki Cattermole wrote: And anyway, it forces us to have good infrastructure going for automated releases. We already have that, I build that in Jan 2014. Unless we have nightlies for e.g. installers, I'm not quite sure its going far enough. Although shouldn't be much of a stretch now (or atleast its not advertised anywhere).
LDC 0.15.1 is out!
Hi everyone, LDC 0.15.1, the LLVM-based D compiler, is available for download! This release is based on the 2.066.1 frontend and standard library and supports LLVM 3.1-3.5 (OS X: no support for 3.3). Don't miss to check if your preferred system is supported by this release. There is even an alpha-quality Win64 version available! As usual, you can find links to the changelog and the binary packages over at digitalmars.D.ldc: http://forum.dlang.org/post/zpjjzbkwlisjemoxu...@forum.dlang.org Regards, Kai
Blog: making sure your D projects won't break
Short story about my attempt to put a bit more efforts in detecting user projects breakage by compiler changes: http://blog.dicebot.lv/2014/12/making-sure-your-d-projects-wont-break.html Quoting important bit: It is quite likely that only few of you will want to spend that much time to simply be able to report regressions in time. I'd still want to see much more healthy library ecosystem out there thus simple proposal - poke me via e-mail and I will gladly add any of you projects to the system I have already configured. There is a one requirement though : you must be willing to actually investigate found regressions and report them to bugzilla or workaround in your project. If that sounds OK to you, just let me know Ironically not a single of few projects I have tried adding currently compiles with a dmd git master - will add more as issues get resolved.
Re: D game development: a call to action
On 12/13/2014 11:39 PM, Manu via Digitalmars-d wrote: On 14 December 2014 at 17:25, Walter Bright via Digitalmars-d digitalmars-d@puremagic.com wrote: On 12/13/2014 5:00 PM, Manu via Digitalmars-d wrote: my engine: https://github.com/TurkeyMan/fuji Please set fuji up at http://code.dlang.org ! It's totally incompatible with dub. How does code.dlang.org deal with foreign build systems? It's very complex to package, since it supports so many optional features, platforms, and various multimedia API's for each platform. I use premake to create projects/makefiles, which I've been maintaining D support for years. The typical way is to just make the engine repo a submodule and extend the buildsystem to the host app (FeedBack is the best example). The thing is, merely having the code there on github and referring to it now and then in the n.g. will result in likely: 0 users. People are going to look for code like yours on code.dlang.org, and if it isn't there, they will assume it does not exist. Build it and they will come is a stupid hollywood myth. It will never happen. So many excellent D projects have died because the creators did: 0 promotion, and nobody used it. Please do not let this happen to your work! I recommend: 1. find a way to make it work on dub. Ask for help. (Martin and Dmitry have been graciously helping me get my code up on dub.) 2. write article(s) about it, post them on your blog site, and ask someone to link 'em to Reddit. 3. announce it on gamedev.net 4. talk about it everywhere on the internet where game devs hang out 5. submit a presentation proposal about it for Dconf 2015, and every other programming conference. How about YOW 2015, it's even in Australia! P.S. This applies to everyone writing open source D projects.
Re: D game development: a call to action
On Sun, 14 Dec 2014 17:45:06 +1000 Manu via Digitalmars-d digitalmars-d@puremagic.com wrote: Hard to describe... just the sort you'd find in a big commercial game. Perhaps I could say something like, highly optimised and purpose specific, as opposed to generalised and flexible/object oriented. i've seen such code. it's... ah, it's terrible. unmaintainable. and becomes garbage just when the next 3d-accel or processor is out. sure, nobody cares as it is sold million times already and everyone is working on another pile of shit now. libraries? code reusability? design? architecture? screw that! i moved out of that industry 'cause i couldn't take it anymore. they almost ruined my programming skills. that's why i was so wondered. Where did you work? It sounds like you had a bad experience. I've worked in a few such environments, I can say we only got the balance right once. ah, that was... outhouse team, i think. we were not officialy part of the main firm, but were working on their titles. it doesn't really matter, i don't know what's going on there now, so let it be the nameless one. ;-) maybe i was just unlucky. i've dreamt of creating videogames from my childhood and was very excited to work in real videogaming industry. that was more than decade ago, though, but i don't believe that things are changed radically since then. i was talking with some old mates recently (they are still making videogames) and was really wondered: they know alot about overhead of memory allocation, processor caches, videodriver glitches, but failing at basic CS things, such as why crc32 isn't good function for hashing?. they know that crc32 should not be used in hashtables, but for what reason... it's mystery. I find a much bigger problem is tendency for some programmers to commit over-abstraction, sacrificing heaps of efficiency/performance in the process. Most open-source engines are this kind, and will never release a AAA game in a competitive market. ah, that's the other end of the spectrum (and my own problem too ;-). i'm still searching for good heuristic that will tell me when i should stop abstracting and just write the damn thing. ;-) signature.asc Description: PGP signature
Re: D game development: a call to action
I did some googling on your game engine: http://fujiengine.org/ Good, but needs more info on why someone should invest time learning it. https://code.google.com/p/fuji/wiki/Platforms Not so good. Says it's Not maintained/out of date. That's about it for its presence on the intertoobs. Also, it's variously called Mount Fuji Engine, Fuji Engine, Mt Fuji Engine and just Fuji. Need to pick one moniker for it and use that consistently everywhere in order to tie your brand together. Need a logo to tie it all together. Sorry to be so blunt about this, but I want you to succeed!
Lost a new commercial user this week :(
Sadly, I failed to create a new commercial D user this week, and I'm really disappointed. It was rejected for exactly the same practical reasons I've been saying forever. There were a few contributing factors, but by far the most significant factor was the extremely poor Windows environment support and Visual Studio debugging experience. We were trying to use vibe.d, and we encountered bugs. We were unable to build Win64 code (vibe.d doesn't support Win64 it seems), and the 32bit compiler produces useless OMF output. We couldn't link against any of our existing code which was a serious inconvenience, but they were understanding and we worked around it. The real trouble hit when vibe.d's WebSocket support didn't work as advertised; it crashed in various circumstances, and debugging was impossible. vibe.d uses exceptions everywhere, which caused an office full of C/C++ programmers to explode with terror, and Visual Studio completely craps itself when there are exceptions being thrown. We tried the VS debugger, and also Mago. Both presented different kinds of issues, which lead to people seriously questioning the quality of the ecosystem, if 2 out of 2 available debug tools don't work, and for different reasons. We had to revert to running without the debugger, and trying to printf() debug, but that proved to be a massive waste of time, and caused enough distaste to the other engineers that it shattered whatever confidence I had built up in D. The decision was made to abandon ship and revert to node.js, which satisfied our needs within a couple of hours. The result was a bunch of die-hard native C programmers, initially excited to use a native language to write a webserver, instead saying stuff like wow, node.js just worked! that's amazing, javascript is awesome!... and then mocking me about my D language thing. What's the take-away here? Well, like I've been saying endlessly for years now, *first impressions matter*, and quality of tooling matters more than anything. They made comments about the installer, where VisualD's installer failed to remember the path that we installed DMD only moments earlier. They immediately made comments about goto-definition not working, and auto-completion not working reliably. They then made HUGE noises about the quality of documentation. The prevailing opinion was that the D docs, in the eyes of a not-a-D-expert, are basically unreadable to them. The formatting didn't help, there's a lot of noise and a lack of structure in the documentation's presentation that makes it hard to see the information through the layout and noise. As senior software engineers, they basically expected that they should be able to read and understand the docs, even if they don't really know the language, after all, what is the point of documentation if not to teach the language... I tend to agree, I find that I can learn most languages to a basic level by skimming the docs, but the D docs are an anomaly in this way; it seems you have to already know D to be able to understand it effectively. They didn't know javascript either, but skimming the node.js docs they got the job done in an hour or so, after having wasted *2 days* trying to force their way through the various frictions presented but their initial experience with D. I have spent months discussing D with other engineers, dropping little tidbits and details out to the floor here and there, getting people excited and jazzed to try something new, and quietly waiting for the opportunity to arise where I can suggest writing some new code in D. I have spent months where people are coming up to me most days asking about some shit thing in C/C++ and how D does it better, to which I usually have a good answer for them, and they walk away excited. ...the moment came. I've built confidence and excitement in these people, but when their first impression is a shambles, it completely undoes all that work, and almost completely shattered their confidence. I also feel personally hurt. I'm frequently putting my reputation on the line when I recommend D to organisations I work in, and all my colleagues. And in this case, I received a serious blow, and that's hard to swallow. I want to see flawless debugging put on the road map as top priority. We need a test environment for the windows installer and VS integration that is thorough and that we can depend on. It's 10 years overdue. We need to get this practical shit together if people are going to take D seriously! I think most importantly though, we need LDC! Assuming those other things come good, we need a compiler with a backend to produce the expected performance, and which integrates in a well known way with the ecosystem around it. Currently, I understand that the only outstanding issue with LDC for Windows is the debuginfo output? I think this is mainly with the LLVM crew, but is there anything we can do to help with this? One of the take-away quotes I think, was D seems to be a
Re: D game development: a call to action
On 14 December 2014 at 17:55, Walter Bright via Digitalmars-d digitalmars-d@puremagic.com wrote: On 12/13/2014 11:39 PM, Manu via Digitalmars-d wrote: On 14 December 2014 at 17:25, Walter Bright via Digitalmars-d digitalmars-d@puremagic.com wrote: On 12/13/2014 5:00 PM, Manu via Digitalmars-d wrote: my engine: https://github.com/TurkeyMan/fuji Please set fuji up at http://code.dlang.org ! It's totally incompatible with dub. How does code.dlang.org deal with foreign build systems? It's very complex to package, since it supports so many optional features, platforms, and various multimedia API's for each platform. I use premake to create projects/makefiles, which I've been maintaining D support for years. The typical way is to just make the engine repo a submodule and extend the buildsystem to the host app (FeedBack is the best example). The thing is, merely having the code there on github and referring to it now and then in the n.g. will result in likely: 0 users. That's fine, I'm not selling a product or anything. It's for personal use... but I'm perfectly happy for other people to take an interest if they want a professional engine dev helping on their project, and portability to a very wide range of systems. People are going to look for code like yours on code.dlang.org, and if it isn't there, they will assume it does not exist. Well it's not really D code, it just has quite comprehensive support for D. I've taken a lot of time with the bindings, and making sure D game projects can effectively be developed against my engine. I still consider the D bindings experimental though, and I keep tweaking them ;) I can't make D engine code until D is supported on the menagerie of console platforms that I support. We need better bare-metal support and more working toolchains. Build it and they will come is a stupid hollywood myth. It will never happen. So many excellent D projects have died because the creators did: 0 promotion, and nobody used it. Please do not let this happen to your work! I recommend: 1. find a way to make it work on dub. Ask for help. (Martin and Dmitry have been graciously helping me get my code up on dub.) Trouble with this is, I'm not interested in dub. An exclusive language-specific build ecosystem is of absolutely no use to me! If I'm mistaken about dub though and I could theoretically somehow make this work, I'm certainly willing to work with anyone who knows better than me how to get it working? 2. write article(s) about it, post them on your blog site, and ask someone to link 'em to Reddit. 3. announce it on gamedev.net 4. talk about it everywhere on the internet where game devs hang out These are all good ideas, but I'm not really actually pimping a project here. I'm not sure it's a project that I'll ever consider 'finished'. It's had 12 years of work, and it's pretty robust and capable, but I just don't have the time to finish/polish off all the stuff I want to. I tend to work in a reactionary manner to emergent requirements :/ I am super happy for those requirements to be someone elses requirements though, and I'm all good to give some of my time to help get other peoples cool projects running well. 5. submit a presentation proposal about it for Dconf 2015, and every other programming conference. How about YOW 2015, it's even in Australia! P.S. This applies to everyone writing open source D projects. Maybe one day I will, I like that idea, but I don't think that day is particularly soon with this project. I need to give it more undivided attention to get it to that state.
Re: Lost a new commercial user this week :(
On Sun, 14 Dec 2014 18:37:26 +1000 Manu via Digitalmars-d digitalmars-d@puremagic.com wrote: docs, even if they don't really know the language, after all, what is the point of documentation if not to teach the language... i think that something is *VERY* wrong with them. for teaching the language we have textbooks, and documentation is for those who already knows the language. each time i see the documentation that wants to teach me basics i crying and my eyes are bleeding. i immediately want to commit a homicide. but i understand your reasoning here, albeit it has nothing in common with mine. signature.asc Description: PGP signature
Re: DIP69 - Implement scope for escape proof references
On Sunday, 14 December 2014 at 00:45:06 UTC, Manu via Digitalmars-d wrote: On 13 December 2014 at 15:11, Walter Bright via Digitalmars-d A function template is a function that takes both compile-time args and run-time args. C++ tried to make them completely different animals, when they are not. Don't think template, think compile-time argument to a function. I convinced Andrei to never mention template in his D book, as it brings forth all kinds of connotations and expectations that impede understanding what D templates actually are. I think the result was successful. You can spin it however you like, but it's exactly the same thing. They are completely different animals. A function template is not a function at all until it's instantiated. When it's instantiated, it becomes a function, or even, one of a suite of functions. And it's not known to the author where the function is. (Note: I define 'function' in this context to mean 'some code that is emitted') Philippe Sigaud Excellent D Templates: A Tutorial... the MANTRA... XXX templates are not XXXs, they are templates. With XXX being any of (function, struct, class, interface, union). --- /Paolo
Re: Lost a new commercial user this week :(
On 14/12/2014 9:37 p.m., Manu via Digitalmars-d wrote: Sadly, I failed to create a new commercial D user this week, and I'm really disappointed. It was rejected for exactly the same practical reasons I've been saying forever. There were a few contributing factors, but by far the most significant factor was the extremely poor Windows environment support and Visual Studio debugging experience. We were trying to use vibe.d, and we encountered bugs. We were unable to build Win64 code (vibe.d doesn't support Win64 it seems), Yup, unfortunately I don't really have the knowledge or the willingness to get it. Otherwise this would have been fixed long ago. and the 32bit compiler produces useless OMF output. We That has already been sorted out in master after all. So getting there. couldn't link against any of our existing code which was a serious inconvenience, but they were understanding and we worked around it. The real trouble hit when vibe.d's WebSocket support didn't work as advertised; it crashed in various circumstances, and debugging was impossible. What I wish happened with Vibe.d is to scope it really REALLY down. It is not a web service framework. It is a web SERVER framework. There is a big difference such as WebSocket proberbly shouldn't even be in Vibe.d. vibe.d uses exceptions everywhere, which caused an office full of C/C++ programmers to explode with terror, and Visual Studio completely craps itself when there are exceptions being thrown. Unfortunately I'm in the camp of, if exceptions don't work. Don't use Vibe.d. We tried the VS debugger, and also Mago. Both presented different kinds of issues, which lead to people seriously questioning the quality of the ecosystem, if 2 out of 2 available debug tools don't work, and for different reasons. Debugger is asking for trouble :/ We had to revert to running without the debugger, and trying to printf() debug, but that proved to be a massive waste of time, and caused enough distaste to the other engineers that it shattered whatever confidence I had built up in D. The decision was made to abandon ship and revert to node.js, which satisfied our needs within a couple of hours. The result was a bunch of die-hard native C programmers, initially excited to use a native language to write a webserver, instead saying stuff like wow, node.js just worked! that's amazing, javascript is awesome!... and then mocking me about my D language thing. What's the take-away here? Well, like I've been saying endlessly for years now, *first impressions matter*, and quality of tooling matters more than anything. They made comments about the installer, where VisualD's installer failed to remember the path that we installed DMD only moments earlier. They immediately made comments about goto-definition not working, and auto-completion not working reliably. For some strange reason I have never liked VS or VisualD. They then made HUGE noises about the quality of documentation. The prevailing opinion was that the D docs, in the eyes of a not-a-D-expert, are basically unreadable to them. The formatting didn't help, there's a lot of noise and a lack of structure in the documentation's presentation that makes it hard to see the information through the layout and noise. As senior software engineers, they basically expected that they should be able to read and understand the docs, even if they don't really know the language, after all, what is the point of documentation if not to teach the language... I tend to agree, I find that I can learn most languages to a basic level by skimming the docs, but the D docs are an anomaly in this way; it seems you have to already know D to be able to understand it effectively. They didn't know javascript either, but skimming the node.js docs they got the job done in an hour or so, after having wasted *2 days* trying to force their way through the various frictions presented but their initial experience with D. Agreed its rather an interesting position. But that's why there is e.g. Ali's book and TDPL to do just that teach. This should proberbly be made into a big flashing banner, wanna learn D?, go here! I have spent months discussing D with other engineers, dropping little tidbits and details out to the floor here and there, getting people excited and jazzed to try something new, and quietly waiting for the opportunity to arise where I can suggest writing some new code in D. I have spent months where people are coming up to me most days asking about some shit thing in C/C++ and how D does it better, to which I usually have a good answer for them, and they walk away excited. ...the moment came. I've built confidence and excitement in these people, but when their first impression is a shambles, it completely undoes all that work, and almost completely shattered their confidence. I also feel personally hurt. I'm frequently putting my reputation on the line when I recommend D to organisations I work in, and
Re: DIP69 - Implement scope for escape proof references
On Sun, 14 Dec 2014 09:04:58 + Paolo Invernizzi via Digitalmars-d digitalmars-d@puremagic.com wrote: Philippe Sigaud Excellent D Templates: A Tutorial... the MANTRA... XXX templates are not XXXs, they are templates. With XXX being any of (function, struct, class, interface, union). and that still doesn't work. ;-) as a somehow related example i recall my first expirience with C. my first serious language was Pascal, and it has that nice range-checking feature for arrays. it was very hard for me to understand that C has no arrays at all, not to say range checking. why there is no arrays if i have this nice indexing and all that?! what do you mean by that buffer overflow nonsence? if it looks like an array it must be an array! signature.asc Description: PGP signature
Re: Lost a new commercial user this week :(
On Sun, 14 Dec 2014 22:13:13 +1300 Rikki Cattermole via Digitalmars-d digitalmars-d@puremagic.com wrote: Now I'm back to the GUI situation. talking about GUI toolkits. there is NONE. yep, i know about DWT, GtkD and alot of other projects. they suck. they suck badly. there was a great project once, Harmonia, but it is dead. DWT suck being java-rooted, and java GUI toolkits are piles of crap. other suck being just a wrappers. there is no GUI toolkit that utilises some kind of markup language, constraint engine (cassowary, anyone?), easy FX without writing boilerplate code, theming and not being a fscking wrapper. yes, i know: if you want to have something, stop ranting and just do it! yet i have alot of other hobby projects and only 24 hours in a day. poor me. signature.asc Description: PGP signature
Re: Lost a new commercial user this week :(
On Sun, 14 Dec 2014 11:24:30 +0200 ketmar via Digitalmars-d digitalmars-d@puremagic.com wrote: On Sun, 14 Dec 2014 22:13:13 +1300 Rikki Cattermole via Digitalmars-d digitalmars-d@puremagic.com wrote: Now I'm back to the GUI situation. talking about GUI toolkits. there is NONE. yep, i know about DWT, GtkD and alot of other projects. they suck. they suck badly. there was a great project once, Harmonia, but it is dead. DWT suck being java-rooted, and java GUI toolkits are piles of crap. other suck being just a wrappers. there is no GUI toolkit that utilises some kind of markup language, constraint engine (cassowary, anyone?), easy FX without writing boilerplate code, theming and not being a fscking wrapper. yes, i know: if you want to have something, stop ranting and just do it! yet i have alot of other hobby projects and only 24 hours in a day. poor me. p.s. sorry for me being rude. DWT, GtkD and others are great project of great value. it's not about their authors doing wrong things, that's about i want something completely different! signature.asc Description: PGP signature
i want my bounty!
there is preapproved bounty ER in bugzilla: https://issues.dlang.org/show_bug.cgi?id=11070 i did that, where is my bounty?! but talking seriously, i don't need any bounty, i just want somebody to take a look at that and either tell me what to fix or integrate it in mainline. along with this one: https://issues.dlang.org/show_bug.cgi?id=13526 they are small, but nice additions. i'm using that patches on dayly basis and didn't found any troubles with them. please, take those, so i can throw away two .patch files from my build directory! ;-) signature.asc Description: PGP signature
Re: Lost a new commercial user this week :(
On 14/12/2014 10:27 p.m., ketmar via Digitalmars-d wrote: On Sun, 14 Dec 2014 11:24:30 +0200 ketmar via Digitalmars-d digitalmars-d@puremagic.com wrote: On Sun, 14 Dec 2014 22:13:13 +1300 Rikki Cattermole via Digitalmars-d digitalmars-d@puremagic.com wrote: Now I'm back to the GUI situation. talking about GUI toolkits. there is NONE. yep, i know about DWT, GtkD and alot of other projects. they suck. they suck badly. there was a great project once, Harmonia, but it is dead. DWT suck being java-rooted, and java GUI toolkits are piles of crap. other suck being just a wrappers. there is no GUI toolkit that utilises some kind of markup language, constraint engine (cassowary, anyone?), easy FX without writing boilerplate code, theming and not being a fscking wrapper. yes, i know: if you want to have something, stop ranting and just do it! yet i have alot of other hobby projects and only 24 hours in a day. poor me. p.s. sorry for me being rude. DWT, GtkD and others are great project of great value. it's not about their authors doing wrong things, that's about i want something completely different! Yeah they are great projects. But they won't ever be what I'm looking for. Personally? - I want a gui toolkit that is accelerated e.g. OpenGL. - That can be layered drawn on top of other OpenGL content. - Completely configurable at runtime e.g. change of shaders. - Centralized themeing. - That works on all major platforms without heartache. But here's the thing about guis in general. Gui toolkits are not really designed to work with OpenGL like this. If I want to fix this, I know I can't go around designing the controls for example. Luckily Google has already done this! Even defined default themes, and how controls should be drawn. Now with how I want a gui toolkit to work, it has a lot of benefits. First off, before I can even create a window, well I need a windowing library. Hello Devisualization.Window. Next, okay I can create a window and a context as needed. What about doing some actual drawing? Devisualization.Util:OpenGL So drawing for OpenGL is easy, but that window could really do with an icon.. Devisualization.Image Now lets draw some text! Devisualization.Font Okay, now we are ready for actually ready for controls. Or are we? Nope! Need a scenegraph to instruct when to draw each control. Devisualization.Scenegraph Next step, lets start the actual controls! Well actually.. we already know we have separated out coordinates from events thanks to the scenegraph. So how about a scenegraph with eventing support. Noticing something? That's about quarter of a game engine stack already made. Before even having GUI controls actually being used. Highly modular and implementation replaceable, portable. I'm already exhausted before even considering sound. Also don't forget the colour paletted provided from Google is in either Photoshop or Illustrator formats. So if you want to use them.. hello parser (already made, Devisualization.Util:photoshop_aco).
Re: Lost a new commercial user this week :(
On Sun, 14 Dec 2014 22:52:59 +1300 Rikki Cattermole via Digitalmars-d digitalmars-d@puremagic.com wrote: p.s. sorry for me being rude. DWT, GtkD and others are great project of great value. it's not about their authors doing wrong things, that's about i want something completely different! Yeah they are great projects. But they won't ever be what I'm looking for. Personally? - I want a gui toolkit that is accelerated e.g. OpenGL. - That can be layered drawn on top of other OpenGL content. - Completely configurable at runtime e.g. change of shaders. - Centralized themeing. - That works on all major platforms without heartache. But here's the thing about guis in general. Gui toolkits are not really designed to work with OpenGL like this. GUI toolkits are not really designed. that is. a good GUI toolkit should be able to use any backend the end user want. DirectFB? OpenGL? custom framebuffer library? anything, it should not matter at all. the abstraction GUI toolkint using should be designed like X server. want anything? ask the underlying layer to do that. pixmap with gradient? don't do that in control painting code, ask the underlying pixmap layer to do that. want text output? don't do that, use the underlying layer that does ALL text rendering. and so on. this way GUI toolkit can use any acceleration the underlying layer can provide. and writing new control is a matter of compositing some high-level calls. and if we'll go to the design stage, we can find markup language useful. with markup language and constraint engine we moving our rendering code even further away. thus we need two layers: basic rendering engine that can draw pixels, and markup processing engine that convert our declarative GUI description to basic operations. and then comes the things like OpenGL, shaders and so on. on the lower level, which can be controlled from markup. do we have only framebuffer? ok, ignore advanced styling and degrate to that. modern OpenGL with shaders? ok, pass the necessary info down the pipe. that's where Devisualisation comes into play. it provides mechanics we need, with simple and well-defined interface. what we also need is high-level engine that will convert our declarative GUI descriptions to low-level calls. HTML is not the best language to build GUIs, but the overall way Harmonia takes looking fine. declarative language for high-level descriptions and translation layer for low-level calls. signature.asc Description: PGP signature
Re: Lost a new commercial user this week :(
On 14/12/2014 11:15 p.m., ketmar via Digitalmars-d wrote: On Sun, 14 Dec 2014 22:52:59 +1300 Rikki Cattermole via Digitalmars-d digitalmars-d@puremagic.com wrote: p.s. sorry for me being rude. DWT, GtkD and others are great project of great value. it's not about their authors doing wrong things, that's about i want something completely different! Yeah they are great projects. But they won't ever be what I'm looking for. Personally? - I want a gui toolkit that is accelerated e.g. OpenGL. - That can be layered drawn on top of other OpenGL content. - Completely configurable at runtime e.g. change of shaders. - Centralized themeing. - That works on all major platforms without heartache. But here's the thing about guis in general. Gui toolkits are not really designed to work with OpenGL like this. GUI toolkits are not really designed. that is. a good GUI toolkit should be able to use any backend the end user want. DirectFB? OpenGL? custom framebuffer library? anything, it should not matter at all. Agreed and I know. I'm using OpenGL as an example. You'll notice heavily that I abstract interface from implementation to the point of there is literally a subpackage called opengl for the OpenGL implementation. the abstraction GUI toolkint using should be designed like X server. want anything? ask the underlying layer to do that. pixmap with gradient? don't do that in control painting code, ask the underlying pixmap layer to do that. want text output? don't do that, use the underlying layer that does ALL text rendering. and so on. this way GUI toolkit can use any acceleration the underlying layer can provide. and writing new control is a matter of compositing some high-level calls. and if we'll go to the design stage, we can find markup language useful. with markup language and constraint engine we moving our rendering code even further away. thus we need two layers: basic rendering engine that can draw pixels, and markup processing engine that convert our declarative GUI description to basic operations. and then comes the things like OpenGL, shaders and so on. on the lower level, which can be controlled from markup. do we have only framebuffer? ok, ignore advanced styling and degrate to that. modern OpenGL with shaders? ok, pass the necessary info down the pipe. that's where Devisualisation comes into play. it provides mechanics we need, with simple and well-defined interface. what we also need is high-level engine that will convert our declarative GUI descriptions to low-level calls. HTML is not the best language to build GUIs, but the overall way Harmonia takes looking fine. declarative language for high-level descriptions and translation layer for low-level calls. Agreed, I hate to say it, because I'm basing off of Google Material design, I would have to use what ever Google does on Android out of pure ease of porting. So its not something I'm able to create new. Just a new implementation.
Re: Lost a new commercial user this week :(
On Sunday, 14 December 2014 at 08:37:36 UTC, Manu via Digitalmars-d wrote: Sadly, I failed to create a new commercial D user this week, and I'm really disappointed. It was rejected for exactly the same practical reasons I've been saying forever. There were a few contributing factors, but by far the most significant factor was the extremely poor Windows environment support and Visual Studio debugging experience. I find exactly the same issue for every developer that I'm moving from C++ to D under Windows: the bar is very high here. We were trying to use vibe.d, and we encountered bugs. We are using Vibe also here in Milan: it's maintained since a long time, and it has plenty of adopters, but... it's just too big. Sönke is doing a remarkable job, but, for example, I've a mail server in production using vibe with an assert turned into an hard exit restart: I was simply unable to debug it. And it's also very picky about what compiler to use to have a proper build, at least, lately. Actually I'm on a branch trying to have it run with master, as I need async-socker and C++ support for a product... *sigh* We were unable to build Win64 code (vibe.d doesn't support Win64 it seems), and the 32bit compiler produces useless OMF output. We couldn't link against any of our existing code which was a serious inconvenience, but they were understanding and we worked around it. I tend to agree about debugging, we also need to keep a Win32 application live, and it's a mess. I know that there's some improvement over that lately, but practically we are developing and debugging it in linux and just running the unittests in Win32. Regarding Vibe, why aren't you using linux for such a job? I think that's the right tool for that kind of services, and life is more easier in that land. The real trouble hit when vibe.d's WebSocket support didn't work as advertised; it crashed in various circumstances, and debugging was impossible. vibe.d uses exceptions everywhere, which caused an office full of C/C++ programmers to explode with terror, and Visual Studio completely craps itself when there are exceptions being thrown. Yep, I can understand, and the documentation does not help a lot, I would say. I think vibe is simply too ambitious: it should take the road of being split, with some pieces being somehow absorbed by Phobos (like the new concurrency). I'm planning to switch to Etienne package for simple socket applications... We tried the VS debugger, and also Mago. Both presented different kinds of issues, which lead to people seriously questioning the quality of the ecosystem, if 2 out of 2 available debug tools don't work, and for different reasons. We had to revert to running without the debugger, and trying to printf() debug, but that proved to be a massive waste of time, and caused enough distaste to the other engineers that it shattered whatever confidence I had built up in D. The decision was made to abandon ship and revert to node.js, which satisfied our needs within a couple of hours. That's the point... I can simply impone to adopt D, because I've the power of doing that, but trying to evangelize bottom-up it seems to me a via crucis... The result was a bunch of die-hard native C programmers, initially excited to use a native language to write a webserver, instead saying stuff like wow, node.js just worked! that's amazing, javascript is awesome!... and then mocking me about my D language thing. *sigh*, but hey: I really hate Javascript (but I'm using it with Meteor...) They then made HUGE noises about the quality of documentation. snip I don't agree here: just go with books. Thanks to Ali, Andrej, Philippe and Adam for covering well that field. It's painful to accept the truth in that statement. Go and try and learn any other trendy language today. The homepage looks modern, there has been professional design, testing, and there are instructional videos recorded by a professional voice actor with that trendy bloody upbeat ukulele music in the background that's in all tech videos these days... I think we need a budget for presentation, and we need to pay money and hire some professionals to make the content. Is there a kickstarter campaign here? I'll contribute for sure. I disagree here: the most beautiful advertising for D are concrete success stories out in the wilds. So first, it needs to stop loosing commercial adopters: why they dropped it, that's the most valuable feedback for the D community. And, IMHO, in THAT specific case, it was: - debugging experience must be top class - async-io as a basic operation, choosing vibe as the 'de-facto' most suitable solution, it's not available for neither the big-two, Lin/Win (OS X is a no-go platform for D until the support to ObjC will be merged). --- /Paolo
Re: Lost a new commercial user this week :(
Thanks for the feedback. On Sunday, 14 December 2014 at 08:37:36 UTC, Manu via Digitalmars-d wrote: We were unable to build Win64 code (vibe.d doesn't support Win64 it seems), and the 32bit compiler produces useless OMF output. We couldn't link against any of our existing code which was a serious inconvenience, but they were understanding and we worked around it. Did you try the new 32-bit COFF support in dmd from git? The result was a bunch of die-hard native C programmers, initially excited to use a native language to write a webserver, instead saying stuff like wow, node.js just worked! that's amazing, javascript is awesome!... and then mocking me about my D language thing. die-hard native C programmers who are fine with javascript? Is it one or two orders of magnitude slower than vibe.d? ;) I know v8 is fast for javascript, but it has to be significantly slower than C and D. What's the take-away here? Well, like I've been saying endlessly for years now, *first impressions matter*, and quality of tooling matters more than anything. ---snip--- I want to see flawless debugging put on the road map as top priority. We need a test environment for the windows installer and VS integration that is thorough and that we can depend on. It's 10 years overdue. We need to get this practical shit together if people are going to take D seriously! ---snip--- One of the take-away quotes I think, was D seems to be a language for people who actively want to go and look for it, and take the time to learn it. That's never going to be a commercial success. It's painful to accept the truth in that statement. Go and try and learn any other trendy language today. The homepage looks modern, there has been professional design, testing, and there are instructional videos recorded by a professional voice actor with that trendy bloody upbeat ukulele music in the background that's in all tech videos these days... There has never been a successful open source project without significant commercial support, going from linux to perl on down the line. D's commercial support consists of some Facebook bounties, Sociomantic throwing out huge pulls occasionally that never get merged, and companies like EMSI chipping in where they can. D will never have commercial success through the higher quality tooling and presentation you are calling for without more significant commercial involvement to fund it, period. Right now, D is bleeding-edge technology. You have to know how to stay away from the chipper blades of the D chainsaw or it could cut your arm open and you could bleed out. Not a problem for hobbyists, but a big problem for companies, who are used to all the rough edges being sanded down and paying through the nose for such support. If decision-makers at companies are hoping to get such polished work for free from a volunteer-oriented OSS project, they should have their heads examined. On Sunday, 14 December 2014 at 09:13:20 UTC, Rikki Cattermole wrote: Great example, how about separating out Walters website from D's? Or one Google indexed web interface to the news group. Great idea, I mentioned this before and nothing was done: http://forum.dlang.org/post/lqpwiaqeyartbsokd...@forum.dlang.org What's especially embarrassing is the old web archive will often garble posts and render them unreadable.
Re: Lost a new commercial user this week :(
On 14/12/2014 11:36 p.m., Joakim wrote: On Sunday, 14 December 2014 at 09:13:20 UTC, Rikki Cattermole wrote: Great example, how about separating out Walters website from D's? Or one Google indexed web interface to the news group. Great idea, I mentioned this before and nothing was done: http://forum.dlang.org/post/lqpwiaqeyartbsokd...@forum.dlang.org What's especially embarrassing is the old web archive will often garble posts and render them unreadable. IMO its an PR disaster. I wonder if somebody would be willing to lend Walter a hand with some redesigning. Although I think it would be a tough sell.
Re: Lost a new commercial user this week :(
On Sunday, 14 December 2014 at 10:36:27 UTC, Joakim wrote: Thanks for the feedback. On Sunday, 14 December 2014 at 08:37:36 UTC, Manu via Digitalmars-d wrote: We were unable to build Win64 code (vibe.d doesn't support Win64 it seems), and the 32bit compiler produces useless OMF output. We couldn't link against any of our existing code which was a serious inconvenience, but they were understanding and we worked around it. Did you try the new 32-bit COFF support in dmd from git? The result was a bunch of die-hard native C programmers, initially excited to use a native language to write a webserver, instead saying stuff like wow, node.js just worked! that's amazing, javascript is awesome!... and then mocking me about my D language thing. die-hard native C programmers who are fine with javascript? Is it one or two orders of magnitude slower than vibe.d? ;) I know v8 is fast for javascript, but it has to be significantly slower than C and D. ... I have seen this in every project where we replaced legacy C++ systems by new ones implemented in .NET and Java. First people will complain that the performance isn't comparable, they are bloated, and so on. The project goes forward, as it was a management decision. Then it goes live, some hiccups that make existing C++ developers rejoice that they were right after all Lots of bug reports get generated and application performance gets fine-tuned. A few months later systems are running, end users barely see any difference and a few C++ developers saying that the new systems aren't that bad after all. -- Paulo
Re: Lost a new commercial user this week :(
On Sunday, 14 December 2014 at 10:31:29 UTC, Paolo Invernizzi wrote: We are using Vibe also here in Milan: it's maintained since a long time, and it has plenty of adopters, but... it's just too big. Sönke is doing a remarkable job, but, for example, I've a mail server in production using vibe with an assert turned into an hard exit restart: I was simply unable to debug it. And it's also very picky about what compiler to use to have a proper build, at least, lately. Actually I'm on a branch trying to have it run with master, as I need async-socker and C++ support for a product... *sigh* If you don't need high-performance, consider using DHSL: https://github.com/canidae/DHSL Example web-service here: https://github.com/p0nce/leaderboard-d Not an all in one solution, but single-file and that means you can use separate libraries for HTML templating, encryption, e-mail, MIME, serialization, etc...
Re: DIP69 - Implement scope for escape proof references
On Sunday, 14 December 2014 at 00:45:06 UTC, Manu via
Digitalmars-d wrote:
Perhaps scope and RC are different things?
Solve scope purely for RC, and you've broken scope for other
purposes
that it's useful; that is, inhibiting escaping of data.
Exactly. It shouldn't matter which type this data has - both
references and value types are valid. I would define `scope` like
this:
A value designated with `scope` may not be assigned to a
variable (or parameter, ...) with a lifetime longer than its
owner's lifetime.
Maybe there's a compromise. If we say scope isn't
'transitive', but it
is transitive when it comes to aggregates?
One thing I've tried very hard to make work in D is have basic
types /
aggregages / arrays be interchangeable.
It should only be applicable to whatever is explicitly marked as
`scope`. For references, that's the reference itself, but not
what it points to. For aggregates, it's the entire aggregate with
all it's members. That way, all types will be treated uniformly.
Of course, this can only work with a type modifier, not with a
storage class.
I'm looking for ways to make scope fit your proposed mould and
be useful to me.
If I can't do this then my most common use case is unsatisfied:
struct Wrap
{
OpaqueThing *ptr;
this() {}
~this() {} // - constructors that twiddle RC effectively.
this(this) {}
this() scope {}
~this() scope {} // - Overloadable for 'scope', in which
case,
don't twiddle the RC!
this(this) scope {}
// lots of operations on OpaqueThing wrapped up here...
}
void f(scope Wrap x) -- RC twiddling is effectively elided
here due
to constructor overloads
{
}
If you can propose an alternative solution?
This is representative of my 99% case. Sometimes the struct is
more
than a single pointer though.
Unfortunately Walter rejected this when I had proposed it.
In the current proposal, we cannot overload on scope. The
proposed solution is to not borrow the wrapper, but only its
payload.
But this is restrictive; even in the case of RC, there are
use-cases that cannot be served with this technique, namely when
the callee can only decide at runtime whether it wants to make a
copy of an RC value it received. The correct solution would be to
pass the RC wrapper itself as scope, as you show in your example,
thereby delegating the decision of whether to adjust the refcount
from the caller to the callee.
Re: Lost a new commercial user this week :(
On Sunday, 14 December 2014 at 12:38:00 UTC, ponce wrote: On Sunday, 14 December 2014 at 10:31:29 UTC, Paolo Invernizzi wrote: And it's also very picky about what compiler to use to have a proper build, at least, lately. Actually I'm on a branch trying to have it run with master, as I need async-socket and C++ support for a product... *sigh* If you don't need high-performance, consider using DHSL: https://github.com/canidae/DHSL Example web-service here: https://github.com/p0nce/leaderboard-d Not an all in one solution, but single-file and that means you can use separate libraries for HTML templating, encryption, e-mail, MIME, serialization, etc... Thank you for the suggestion ponce, but I need a little more (fibers, file, socket, timers, ...). --- Paolo
Re: Lost a new commercial user this week :(
On Sunday, 14 December 2014 at 11:53:56 UTC, Paulo Pinto wrote: I have seen this in every project where we replaced legacy C++ systems by new ones implemented in .NET and Java. First people will complain that the performance isn't comparable, they are bloated, and so on. The project goes forward, as it was a management decision. Then it goes live, some hiccups that make existing C++ developers rejoice that they were right after all Lots of bug reports get generated and application performance gets fine-tuned. A few months later systems are running, end users barely see any difference and a few C++ developers saying that the new systems aren't that bad after all. I don't doubt that this has been your experience on enterprise projects with a known and stable userbase, but you can't tell me you were able to support the same amount of users per server using java/.net as C++. Paying for more servers but less for java/.net development may be a worthwhile tradeoff for such stable enterprise rollouts, but any time you have to scale, I doubt java/.net can keep up. As always, different tools for different uses. Hopefully, D can one day be polished and mainstream enough for the enterprise use case and it will be efficient enough to be deployed at scale too. :)
DUB fails to build a dynamic library on Linux
Hello,
I've created a simple db dynamic lib project.
dub.json:
{
name: node-d-sample,
description: A minimal D application.,
copyright: Copyright © 2014, gabor,
authors: [gabor],
dependencies: {
},
libs: [ phobos2 ],
targetName: node-d-sample,
targetPath: lib,
targetType: dynamicLibrary
}
I have only one source, lib.d:
extern (C)
{
int ping()
{
return 555;
}
}
My system is a Mint x64, dub latest, dmd latest.
If I invoke dub, then:
Building node-d-sample ~master configuration library, build
type debug.
Compiling using dmd...
Linking...
/usr/bin/ld:
.dub/build/library-debug-linux.posix-x86_64-dmd_2066-44F775BF77E519551012EFF79429BBA3/node-d-sample.o:
relocation R_X86_64_32 against `.rodata' can not be used when
making a shared object; recompile with -fPIC
.dub/build/library-debug-linux.posix-x86_64-dmd_2066-44F775BF77E519551012EFF79429BBA3/node-d-sample.o:
error adding symbols: Bad value
collect2: error: ld returned 1 exit status
--- errorlevel 1
FAIL
.dub/build/library-debug-linux.posix-x86_64-dmd_2066-44F775BF77E519551012EFF79429BBA3/
node-d-sample dynamicLibrary
Error executing command run: dmd failed with exit code 1.
Re: Lost a new commercial user this week :(
I agree about the general debugging experience on Windows. It's improving (at least with Mago), but still not where it should be. Partially this would be easy to remedy, such as in case of omitted stack frames in Phobos, as mentioned in Vladimir's recent thread that I just skimmed through. Just quickly commenting on the vibe.d specific issues. If you have filed any recent bug reports and I didn't respond, this is because I way barely able to work on a computer at all during the past weeks. I'll try to start catching up a little bit now. Am 14.12.2014 09:37, schrieb Manu via Digitalmars-d: We were trying to use vibe.d, and we encountered bugs. We were unable to build Win64 code (vibe.d doesn't support Win64 it seems), and the 32bit compiler produces useless OMF output. We couldn't link against any of our existing code which was a serious inconvenience, but they were understanding and we worked around it. It does, either by using the win32 configuration instead of libevent, or by manually providing a pre-compiled version of libevent for Win64 (I'd be happy to accept a PR, too). I didn't build it for a while though, so it may be that something is broken. The real trouble hit when vibe.d's WebSocket support didn't work as advertised; it crashed in various circumstances, and debugging was impossible. vibe.d uses exceptions everywhere, which caused an office full of C/C++ programmers to explode with terror, and Visual Studio completely craps itself when there are exceptions being thrown. If you set a breakpoint at __dthrow_c, at least you get a proper call stack. It still doesn't enable accessing the exception internals, but usually those are less important. Regarding exceptions themselves, it looks like the mindset of those C++ programmers is quite fixed, not the best premise for embracing D (but yeah, changing this usually requires some time/effort). Coming from a C and C++ without exceptions/RTTI background myself, I understand very well where that reaction comes from. However, IMO exceptions as a mechanism are very well suited for server environments especially because they cannot be (accidentally) ignored, and they often help a lot to make the code more readable. In a language that has them as a mandatory feature and uses them extensively in its standard library, I simply saw no reason to carry the no-exception rule over to D. Of course they must be used accordingly (only for exceptional situations) and the debugger has to properly support them to make the debugging experience bearable. Having said that, a call stack + error message dumped to stderr is usually all that is needed, so the last point is more of a convenience factor when running from within VS. Lastly, when judging all these things, please always try to remember that almost all the work that goes into D (and vibe.d) is non-profit and everyone usually only contributes what (s)he is missing. If I would get payed through a support contract for my work on vibe.d, I could adjust my priorities to suit the requirements of others more, but like this I still have to somehow make sure to be able to pay my bills and can't just work full time to help other (commercial) projects (although I always try to help as far as possible). Sönke
Re: Lost a new commercial user this week :(
On 14/12/14 09:37, Manu via Digitalmars-d wrote: The formatting didn't help, there's a lot of noise and a lack of structure in the documentation's presentation that makes it hard to see the information through the layout and noise. As senior software engineers, they basically expected that they should be able to read and understand the docs, even if they don't really know the language, after all, what is the point of documentation if not to teach the language... Can you be a bit more precise about what were the stumbling blocks with the documentation? Were there any particular concepts necessary to understand the docs that weren't there? What were the exact things they were trying to do (in terms of accessing and understanding the documentation) that were difficult? Did they give any particular feedback in terms of how they expected things to be organized, and how that differed from what they found? Thank you in any case for trying to get people on board. I'm sorry it was such a negative experience for you all.
Re: DUB fails to build a dynamic library on Linux
You need to add `-fPIC` to your compiler flags. In dub.json: ..., dflags: [-fPIC]
Re: Lost a new commercial user this week :(
On Sunday, 14 December 2014 at 14:09:57 UTC, Joakim wrote: As always, different tools for different uses. Hopefully, D can one day be polished and mainstream enough for the enterprise use case and it will be efficient enough to be deployed at scale too. :) when will that be? windows version 25, sqlite version 1147? in d everybody seem to tinker around - closing a little hole here and there - and forgetting, that this will never lead to a larger acception of the general programming community. i want to use - not experiment or start to waste a lot of time in recreating the things that i get with all the other languages. it's kind funny to watch that excuse finding. i think the leaders of this research project should find a way to make it usable to wider public instead of pursuing their pet projects.
Re: Lost a new commercial user this week :(
On Sunday, 14 December 2014 at 15:36:47 UTC, yawniek wrote: On Sunday, 14 December 2014 at 14:09:57 UTC, Joakim wrote: As always, different tools for different uses. Hopefully, D can one day be polished and mainstream enough for the enterprise use case and it will be efficient enough to be deployed at scale too. :) when will that be? windows version 25, sqlite version 1147? in d everybody seem to tinker around - closing a little hole here and there - and forgetting, that this will never lead to a larger acception of the general programming community. i want to use - not experiment or start to waste a lot of time in recreating the things that i get with all the other languages. it's kind funny to watch that excuse finding. i think the leaders of this research project should find a way to make it usable to wider public instead of pursuing their pet projects. Yeah, I completely agree. We need something like a D foundation, with full time workers, to get to the upper level.
Re: Lost a new commercial user this week :(
On Sunday, 14 December 2014 at 15:36:47 UTC, yawniek wrote: On Sunday, 14 December 2014 at 14:09:57 UTC, Joakim wrote: As always, different tools for different uses. Hopefully, D can one day be polished and mainstream enough for the enterprise use case and it will be efficient enough to be deployed at scale too. :) when will that be? windows version 25, sqlite version 1147? As I said earlier, when D garners significant commercial support. I suggested a commercial model of providing a paid compiler alongside the free compiler last year, but the D core team wasn't interested: http://forum.dlang.org/post/sglcqsiphpntcdlhv...@forum.dlang.org There are other possible commercial models discussed in that thread. D's bounty system was started soon afterwards, but probably isn't used as much as it could be.
Re: DUB fails to build a dynamic library on Linux
On 12/14/2014 03:50 PM, Gabor Mezo wrote: Hello, I've created a simple db dynamic lib project. https://github.com/D-Programming-Language/dub/issues/352
Travis-CI support for D
Cross post from the D.announce newsgroup, to reach a broader audience. http://forum.dlang.org/post/m6b7r2$18ri$1...@digitalmars.com
Re: Lost a new commercial user this week :(
On Sunday, 14 December 2014 at 15:56:20 UTC, Joakim wrote: On Sunday, 14 December 2014 at 15:36:47 UTC, yawniek wrote: On Sunday, 14 December 2014 at 14:09:57 UTC, Joakim wrote: As always, different tools for different uses. Hopefully, D can one day be polished and mainstream enough for the enterprise use case and it will be efficient enough to be deployed at scale too. :) when will that be? windows version 25, sqlite version 1147? As I said earlier, when D garners significant commercial support. I suggested a commercial model of providing a paid compiler alongside the free compiler last year, but the D core team wasn't interested: http://forum.dlang.org/post/sglcqsiphpntcdlhv...@forum.dlang.org There are other possible commercial models discussed in that thread. D's bounty system was started soon afterwards, but probably isn't used as much as it could be. well, i am not so sure that commercial models are needed, but instead of trying to invent a new gui library, make the os available for 32/64. fix all those projects that deal with db, gui etc. get rid of all those misleading, outdated projects with galloping consumption, since people find those projects with the result - it given up, not working all those little patches, and little add-on's are transformed into huge success stories on reddit - man is that getting embarrassing. this language is developed now for over 7 years (i think) and it is still not mainstream usable. what has to be done?
Re: DUB fails to build a dynamic library on Linux
On Sunday, 14 December 2014 at 16:06:25 UTC, Martin Nowak wrote:
On 12/14/2014 03:50 PM, Gabor Mezo wrote:
Hello,
I've created a simple db dynamic lib project.
https://github.com/D-Programming-Language/dub/issues/352
Thanks,
I've did this, it finally build, but something is still not good.
If I call externals from another application, and my D code
allocates anything on heap, the calling process crashes with
SIGSEV. I mean it works:
extern (C)
{
int ping()
{
return 555;
}
}
But it doesn't:
extern (C)
{
int ping()
{
try { throw new Exception(foo); } catch
(Exception ex) { }
return 555;
}
}
or this one crashes too:
extern (C)
{
int ping()
{
auto foo = new Object();
return 555;
}
}
Re: Lost a new commercial user this week :(
On Sun, 14 Dec 2014 16:18:26 + yawniek via Digitalmars-d digitalmars-d@puremagic.com wrote: well, i am not so sure that commercial models are needed, but instead of trying to invent a new gui library, make the os available for 32/64. fix all those projects that deal with db, gui etc. get rid of all those misleading, outdated projects with galloping consumption, since people find those projects with the result - it given up, not working will you pay for all that? 'cause, you know, if people don't get paid, they tend to work on what *they* consider fun. signature.asc Description: PGP signature
Re: DUB fails to build a dynamic library on Linux
I've opened an other thread instead, because this is a different issue. It's there: http://forum.dlang.org/thread/aycvoeaurrpmuehat...@forum.dlang.org#post-aycvoeaurrpmuehatdwp:40forum.dlang.org
Caller of dynamic library crashes with SIGSEV if D code allocates anything on heap.
Hello,
I've opened an other thread for this, because this is a different
issue.
Previous issue is there:
http://forum.dlang.org/thread/zzjeajhjpzhnvgxqu...@forum.dlang.org#post-vuzttuewxyvuihubgtas:40forum.dlang.org
The current issue is if I build a dynamic library with DUB and
call externals form another application, and my D code
allocates anything on heap, the calling process crashes with
SIGSEV.
I mean it works:
extern (C)
{
int ping()
{
return 555;
}
}
But it doesn't:
extern (C)
{
int ping()
{
try { throw new Exception(foo); } catch
(Exception ex) { }
return 555;
}
}
or this one crashes too:
extern (C)
{
int ping()
{
auto foo = new Object();
return 555;
}
}
Re: DUB fails to build a dynamic library on Linux
On Sun, 14 Dec 2014 16:24:13 + Gabor Mezo via Digitalmars-d digitalmars-d@puremagic.com wrote: On Sunday, 14 December 2014 at 16:06:25 UTC, Martin Nowak wrote: On 12/14/2014 03:50 PM, Gabor Mezo wrote: Hello, I've created a simple db dynamic lib project. https://github.com/D-Programming-Language/dub/issues/352 Thanks, I've did this, it finally build, but something is still not good. If I call externals from another application, and my D code allocates anything on heap, the calling process crashes with SIGSEV. did you called `rt_init()` for your dynamic library? you have to do that in the calling process. and don't forget to call `rt_term()` on exiting. signature.asc Description: PGP signature
Re: Why do you write D2 compiler using C++ language?
On Saturday, 13 December 2014 at 23:02:52 UTC, Mike Parker wrote: On 12/13/2014 10:55 PM, ddj wrote: But so many issues and bug fixes scares me from using it. That's just the wrong way to look at it. Take a look at the bug list for gcc, any of the Java compilers, or clang. Are you afraid to use them as well? Maybe, but gcc and java compilers have long history of stable releases and many programs and libraries written. Clang has standards to implement and! static analyzer.
Re: DUB fails to build a dynamic library on Linux
Thank you for your quick help, that was it. I do (or at least I'm trying to do) hobbyist D programming as you guys, that's why I come here to cry at Sunday evening. :) Ok, I'm almost there. It builds with DUB/DMD, I can allocate stuff on the heap, so far so good. But if I invoke: dub --compiler=gdc then I got: Performing main compilation... dub build node-d-sample --arch=x86_64 --compiler=gdc --build=release Building package node-d-sample in /home/gabor/sandbox/node-d-sample/ Building node-d-sample ~master configuration library, build type release. Running gdc... /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/4.9/libgphobos2.a(minfo.o): relocation R_X86_64_32 against `_D32TypeInfo_APxS6object10ModuleInfo6__initZ' can not be used when making a shared object; recompile with -fPIC /usr/lib/gcc/x86_64-linux-gnu/4.9/libgphobos2.a: error adding symbols: Bad value collect2: error: ld returned 1 exit status FAIL .dub/build/library-release-linux.posix-x86_64-gdc_2065-33A38D9D3DC714C1501A18C957A2B35B/ node-d-sample dynamicLibrary Error executing command build: gdc failed with exit code 1. Exit code 2 Build complete -- 1 error, 0 warnings or: dub --compiler=ldmd2 then I got: Performing main compilation... dub build node-d-sample --arch=x86_64 --compiler=ldmd2 --build=release The determined compiler type ldc doesn't match the expected type dmd. This will probably result in build errors. Building package node-d-sample in /home/gabor/sandbox/node-d-sample/ Building node-d-sample ~master configuration library, build type release. Running ldmd2... /usr/bin/ld: /home/gabor/dev/ldc2-0.15.0-beta1-linux-x86_64/bin/../lib/libdruntime-ldc.a(eh.o): relocation R_X86_64_32 against `.rodata..str1' can not be used when making a shared object; recompile with -fPIC /home/gabor/dev/ldc2-0.15.0-beta1-linux-x86_64/bin/../lib/libdruntime-ldc.a: error adding symbols: Bad value collect2: error: ld returned 1 exit status Error: /usr/bin/gcc failed with status: 1 FAIL .dub/build/library-release-linux.posix-x86_64-ldc_2066-212B345732639D80C27025028ED586A2/ node-d-sample dynamicLibrary Error executing command build: ldmd2 failed with exit code 1. Exit code 2 Build complete -- 1 error, 0 warnings It seems DUB somehow eats dflags away for non DMD compilers. How the hell should I prevent this happen? Thanks.
Re: Lost a new commercial user this week :(
On Sunday, 14 December 2014 at 14:09:57 UTC, Joakim wrote: On Sunday, 14 December 2014 at 11:53:56 UTC, Paulo Pinto wrote: I have seen this in every project where we replaced legacy C++ systems by new ones implemented in .NET and Java. First people will complain that the performance isn't comparable, they are bloated, and so on. The project goes forward, as it was a management decision. Then it goes live, some hiccups that make existing C++ developers rejoice that they were right after all Lots of bug reports get generated and application performance gets fine-tuned. A few months later systems are running, end users barely see any difference and a few C++ developers saying that the new systems aren't that bad after all. I don't doubt that this has been your experience on enterprise projects with a known and stable userbase, but you can't tell me you were able to support the same amount of users per server using java/.net as C++. Paying for more servers but less for java/.net development may be a worthwhile tradeoff for such stable enterprise rollouts, but any time you have to scale, I doubt java/.net can keep up. As always, different tools for different uses. Hopefully, D can one day be polished and mainstream enough for the enterprise use case and it will be efficient enough to be deployed at scale too. :) You mean scale like Twitter and LinkedIn? On my case, two examples of such project was a software stack for network monitoring, data aggregation and monitoring for mobile networks all the way down to network elements. The old system was a mix of Perl, C++/CORBA and Motif. The new system is all Java, with small C stack for resource constrained elements. Another example was replacing C++ applications in medicine image analysis with 90% .NET stack and a mix of C++/Assembly for image filters and driver P/Invoke glue. The problem is that the average coders don't learn to optimize code and in the end most business will just shell out money for more hardware than software development time. We had high performance systems running with a stable GC cycles, after doing the required optimization work. That is why tools like VisualVM and Mission Control exist. -- Paulo
Re: DUB fails to build a dynamic library on Linux
On Sun, 14 Dec 2014 16:57:20 + Gabor Mezo via Digitalmars-d digitalmars-d@puremagic.com wrote: Thank you for your quick help, that was it. I do (or at least I'm trying to do) hobbyist D programming as you guys, that's why I come here to cry at Sunday evening. :) ah, that's ok. but you'd better ask your questions in D.learning. not 'cause you're a beginner, but just 'cause D.learning has invalid name. it should be D.questions. besides, when people see the question in general, they tend to give shorter and less detailed answers than in learning. sorry for the noise, as i can't tell you anything about DUB. signature.asc Description: PGP signature
Re: Caller of dynamic library crashes with SIGSEV if D code allocates anything on heap.
I's solved by ketmar: did you called `rt_init()` for your dynamic library? you have to do that in the calling process. and don't forget to call `rt_term()` on exiting. Yea, I missed that. It works. Thanks.
Re: DUB fails to build a dynamic library on Linux
Actually I'm practicing D for about three months but this C interfacing mumbo jumbo is still missing for me. Ok, I'm go there if I'm stuck, thanks.
Re: Lost a new commercial user this week :(
On Sunday, 14 December 2014 at 17:09:31 UTC, Paulo Pinto wrote: On Sunday, 14 December 2014 at 14:09:57 UTC, Joakim wrote: I don't doubt that this has been your experience on enterprise projects with a known and stable userbase, but you can't tell me you were able to support the same amount of users per server using java/.net as C++. Paying for more servers but less for java/.net development may be a worthwhile tradeoff for such stable enterprise rollouts, but any time you have to scale, I doubt java/.net can keep up. You mean scale like Twitter and LinkedIn? Java NIO has the potential to be really scalable, and the new Netty apparently uses it to great effect. You'll never be able to park as many connections using Java as you would in C, but concurrent throughput is probably pretty close when done properly. My issue with Java is just that because of how the library is designed, you're fighting against it by trying to limit dynamic allocations, so it will probably never be a terribly natural experience. At the same time, it is way easier to find competent Java programmers, which is a significant factor when making a business decision. My personal preference is still for C++ done in a similar manner as vibe.d as I think it's the sweet spot between ease of use and scalability provided you have a talented team, but I've seen Java be used successfully for servicing hundreds of millions of users with a high concurrent throughput.
Re: Lost a new commercial user this week :(
On Sunday, 14 December 2014 at 17:09:31 UTC, Paulo Pinto wrote: You mean scale like Twitter and LinkedIn? Maybe that's why they still lose money hand over fist, especially Twitter, because of all the extra servers they have to buy. :p By comparison, Whatsapp was able to put millions of users on a server with erlang and become profitable with much less revenue: http://forum.dlang.org/post/bmvwftlyvlgmuehrt...@forum.dlang.org On my case, two examples of such project was a software stack for network monitoring, data aggregation and monitoring for mobile networks all the way down to network elements. The old system was a mix of Perl, C++/CORBA and Motif. The new system is all Java, with small C stack for resource constrained elements. Another example was replacing C++ applications in medicine image analysis with 90% .NET stack and a mix of C++/Assembly for image filters and driver P/Invoke glue. It is instructive that you're dropping down to C/C++/Assembly in each of these examples: that's not really making the case for java/.net on their own. The problem is that the average coders don't learn to optimize code and in the end most business will just shell out money for more hardware than software development time. Yeah, it's all about the particular job and what the tradeoffs are there. Most online apps don't need to scale to extremes, which is why they're mostly not written in C++.
Re: Lost a new commercial user this week :(
On Sunday, 14 December 2014 at 18:25:26 UTC, Joakim wrote: On Sunday, 14 December 2014 at 17:09:31 UTC, Paulo Pinto wrote: You mean scale like Twitter and LinkedIn? Maybe that's why they still lose money hand over fist, especially Twitter, because of all the extra servers they have to buy. :p By comparison, Whatsapp was able to put millions of users on a server with erlang and become profitable with much less revenue: http://forum.dlang.org/post/bmvwftlyvlgmuehrt...@forum.dlang.org I don't really understand how you can simultaneously advertise Erlang and bash Java for inefficiency. I think the core concurrency model in Erlang is really great, and it scales horizontally to great effect, but it's a bear to do TCP work in and is far less efficient than Java, let alone C++.
Re: Lost a new commercial user this week :(
On Sunday, 14 December 2014 at 18:25:26 UTC, Joakim wrote: On Sunday, 14 December 2014 at 17:09:31 UTC, Paulo Pinto wrote: You mean scale like Twitter and LinkedIn? Maybe that's why they still lose money hand over fist, especially Twitter, because of all the extra servers they have to buy. :p By comparison, Whatsapp was able to put millions of users on a server with erlang and become profitable with much less revenue: http://forum.dlang.org/post/bmvwftlyvlgmuehrt...@forum.dlang.org On my case, two examples of such project was a software stack for network monitoring, data aggregation and monitoring for mobile networks all the way down to network elements. The old system was a mix of Perl, C++/CORBA and Motif. The new system is all Java, with small C stack for resource constrained elements. Another example was replacing C++ applications in medicine image analysis with 90% .NET stack and a mix of C++/Assembly for image filters and driver P/Invoke glue. It is instructive that you're dropping down to C/C++/Assembly in each of these examples: that's not really making the case for java/.net on their own. I was expecting a comment like that. :) On the first case, certain network elements are quite resource constrained, so you just have a real time OS, doing SNMP stuff and other control operations. So only a small C library could bt delivered on those. Everything else capable of running a JIT enabled JVM was doing so. On the medicine example, the C++/Assembly code was being used in two cases: - SIMD (maybe with the upcoming SIMD support on .NET, this wouldn't be needed any longer) - COM, many manufacturers provide only COM drivers for their devices, no way around it. If the was public, .NET networking code could have been used instead as the devices used ethernet. The problem is that the average coders don't learn to optimize code and in the end most business will just shell out money for more hardware than software development time. Yeah, it's all about the particular job and what the tradeoffs are there. Most online apps don't need to scale to extremes, which is why they're mostly not written in C++. Yes, agreed there. However, there are many places that developers use C and C++, not because of speed, rather because for the last decades all the other programming languages with native code compilers faded away. With the current ahead of time native compilation renaissance and GPU support on other languages, the need for C and C++ in such use cases will decrease. Still there are quite a few places where C and C++ will matter (e.g. embedded, OS drivers, HPC, AAA games, ...) in regards to overall computing landscape. -- Paulo
Re: DUB fails to build a dynamic library on Linux
On Sunday, 14 December 2014 at 16:57:24 UTC, Gabor Mezo wrote: /home/gabor/dev/ldc2-0.15.0-beta1-linux-x86_64/bin/../lib/libdruntime-ldc.a(eh.o): relocation R_X86_64_32 against `.rodata..str1' can not be used when making a shared object; recompile with -fPIC Hm, the problem here is that LDC uses a static runtime build, while dynamic libraries require Phobos and druntime to be built as shared libraries. The latter has actually been supported since quite a few months now, but IIRC still isn't shipped as part of the binary packages: https://github.com/ldc-developers/ldc/issues/807 If you want to give it a try, you can quickly build LDC from source (http://wiki.dlang.org/Building_LDC_from_source) and pass the -DBUILD_SHARED_LIBS=ON flag to CMake. Building shared libraries should then succeed. David
Re: Lost a new commercial user this week :(
Im sorry to hear that. So many things went wrong here. This is the way i see it. Basically what you did was introduce a friend of yours to your colleagues with good impressions on just about everything. This is like introducing a friend to me and telling me his a great person even though you know deep down inside you know your friend doesnt have the best personality in the world. What you could have done was be sincere and told your colleagues that D is a great person overall but he does have his drawbacks. That way they know what to expect and are ready and prepared to handle D. Along with that you could have inspired them on a different point of view. You guys are working with JavaScript :/. Doing something with D would have been an extraordinary achievement. Thats like accomplishing a task with a common method. But sometimes you have to take a leap of faith and accomplish that task in a new way. This would have given you and your team unique in a way and probably have given you a good image.
Re: Lost a new commercial user this week :(
On 12/14/2014 12:37 AM, Manu via Digitalmars-d wrote: There were a few contributing factors, but by far the most significant factor was the extremely poor Windows environment support and Visual Studio debugging experience. This is valuable information, while it's fresh in your mind can you please submit a bugzilla issue for each point? They then made HUGE noises about the quality of documentation. The prevailing opinion was that the D docs, in the eyes of a not-a-D-expert, are basically unreadable to them. The formatting didn't help, there's a lot of noise and a lack of structure in the documentation's presentation that makes it hard to see the information through the layout and noise. As senior software engineers, they basically expected that they should be able to read and understand the docs, even if they don't really know the language, after all, what is the point of documentation if not to teach the language... I tend to agree, I find that I can learn most languages to a basic level by skimming the docs, but the D docs are an anomaly in this way; it seems you have to already know D to be able to understand it effectively. They didn't know javascript either, but skimming the node.js docs they got the job done in an hour or so, after having wasted *2 days* trying to force their way through the various frictions presented but their initial experience with D. I understand what you're saying, but I find it hard to figure out just what to do to change it. Any specific suggestions?
Re: DIP69 - Implement scope for escape proof references
On 12/8/2014 7:23 AM, Steven Schveighoffer wrote: What I wanted to know was, when I see scope ref, why is it there? When should I use it? It's there to indicate a parameter is NOT returned by ref. When should I use scope? What nasty things are prevented if I use it? Examples would be preferable. http://wiki.dlang.org/DIP69#Ref has examples of errors that are prevented.
Re: Lost a new commercial user this week :(
On 2014-12-14 09:37, Manu via Digitalmars-d wrote: They immediately made comments about goto-definition not working, and auto-completion not working reliably. I'm curious to know which tools they used to get autocompletion and go-to-definition to work with JavaScript. -- /Jacob Carlborg
Re: Lost a new commercial user this week :(
On Sunday, 14 December 2014 at 19:40:16 UTC, Walter Bright wrote: On 12/14/2014 12:37 AM, Manu via Digitalmars-d wrote: There were a few contributing factors, but by far the most significant factor was the extremely poor Windows environment support and Visual Studio debugging experience. This is valuable information, while it's fresh in your mind can you please submit a bugzilla issue for each point? They then made HUGE noises about the quality of documentation. The prevailing opinion was that the D docs, in the eyes of a not-a-D-expert, are basically unreadable to them. The formatting didn't help, there's a lot of noise and a lack of structure in the documentation's presentation that makes it hard to see the information through the layout and noise. As senior software engineers, they basically expected that they should be able to read and understand the docs, even if they don't really know the language, after all, what is the point of documentation if not to teach the language... I tend to agree, I find that I can learn most languages to a basic level by skimming the docs, but the D docs are an anomaly in this way; it seems you have to already know D to be able to understand it effectively. They didn't know javascript either, but skimming the node.js docs they got the job done in an hour or so, after having wasted *2 days* trying to force their way through the various frictions presented but their initial experience with D. I understand what you're saying, but I find it hard to figure out just what to do to change it. Any specific suggestions? One thing I ran into often when I was inexperienced with D: the template constraints make some signatures extremely messy, and it takes a while to figure out when you have e.g. 3 template functions of the same name in std.algorithm, all with crypric signatures. Example: ptrdiff_t countUntil(alias pred = a == b, R, Rs...)(R haystack, Rs needles) if (isForwardRange!R Rs.length 0 isForwardRange!(Rs[0]) == isInputRange!(Rs[0]) is(typeof(startsWith!pred(haystack, needles[0]))) (Rs.length == 1 || is(typeof(countUntil!pred(haystack, needles[1..$]); ptrdiff_t countUntil(alias pred = a == b, R, N)(R haystack, N needle) if (isInputRange!R is(typeof(binaryFun!pred(haystack.front, needle)) : bool)); countUntil is trivial to use, but the docs make it seem complicated and it takes a while to read them. (This is not really a good example as with countUntil it's not *that* bad, but I think it should be enough to show the problem) In this specific case, it would be useful if the constraint was somehow separated from the rest of the signature and less emphasized (CSS). Also, in this example, the documentation text itself immediately goes into detail (e.g. mentioning startsWith!) instead of starting with a simple explanation of the concept. I think this could be helped somewhat if the example This is one example of too much noise. Example of 'not teaching the language': For the first few months using D, I had no idea what D 'range' (I knew Python) is and it made the docs harder to understand. I think most or all mentions of terms important in D such as 'range' should link to a *simple* explanation of what a range/whatever is (maybe in Ali Cehreli's book?). Also... some docs are just plain lazy (does something similar but not the same as this C function we couldn't even be arsed to link to), missing examples (or missing *useful* examples, etc.) - A lot of docs assume the reader knows some specific other language, not only C I occasionally try to push minor doc fixes but currently I'm rather swamped, may do some work on that next summer.
Re: Lost a new commercial user this week :(
On Sunday, 14 December 2014 at 20:44:17 UTC, Jacob Carlborg wrote: On 2014-12-14 09:37, Manu via Digitalmars-d wrote: They immediately made comments about goto-definition not working, and auto-completion not working reliably. I'm curious to know which tools they used to get autocompletion and go-to-definition to work with JavaScript. It's Webstorm. There you get auto-completion, go-to-definition, refactor, insanely superior debugger, anything that you can dream of. I'm not a Jetbrains sales manager, I'm just doing Node.js coding at my work. :)
Re: Lost a new commercial user this week :(
On Sunday, 14 December 2014 at 20:44:17 UTC, Jacob Carlborg wrote: On 2014-12-14 09:37, Manu via Digitalmars-d wrote: They immediately made comments about goto-definition not working, and auto-completion not working reliably. I'm curious to know which tools they used to get autocompletion and go-to-definition to work with JavaScript. On my area of work, for example Netbeans. https://netbeans.org/features/html5/index.html http://wiki.netbeans.org/NewAndNoteworthyNB80#JavaScript https://netbeans.org/kb/73/ide/javascript-editor.html Visual Studio Web Tools and InteliJ provide similar features. Eclipse is quite bad in comparison. -- Paulo
Re: Lost a new commercial user this week :(
On Sunday, 14 December 2014 at 15:03:27 UTC, Sönke Ludwig wrote: Lastly, when judging all these things, please always try to remember that almost all the work that goes into D (and vibe.d) is non-profit and everyone usually only contributes what (s)he is missing. If I would get payed through a support contract for my work on vibe.d, I could adjust my priorities to suit the requirements of others more, but like this I still have to somehow make sure to be able to pay my bills and can't just work full time to help other (commercial) projects (although I always try to help as far as possible). Sonke, Can you advise how much a support contract for a individual or company seriously interested in using vibe.d might cost ?
Re: Lost a new commercial user this week :(
On 12/14/2014 1:00 PM, Kiith-Sa wrote: I occasionally try to push minor doc fixes but currently I'm rather swamped, may do some work on that next summer. Any help is appreciated, even small things.
Re: Lost a new commercial user this week :(
On Sunday, 14 December 2014 at 18:50:44 UTC, Sean Kelly wrote: On Sunday, 14 December 2014 at 18:25:26 UTC, Joakim wrote: On Sunday, 14 December 2014 at 17:09:31 UTC, Paulo Pinto wrote: You mean scale like Twitter and LinkedIn? Maybe that's why they still lose money hand over fist, especially Twitter, because of all the extra servers they have to buy. :p By comparison, Whatsapp was able to put millions of users on a server with erlang and become profitable with much less revenue: http://forum.dlang.org/post/bmvwftlyvlgmuehrt...@forum.dlang.org I don't really understand how you can simultaneously advertise Erlang and bash Java for inefficiency. I think the core concurrency model in Erlang is really great, and it scales horizontally to great effect, but it's a bear to do TCP work in and is far less efficient than Java, let alone C++. I'm not trying to say erlang is much more efficient in the general case than Java, as I've heard it isn't, but that they chose a language and OS that was highly optimized for their use, concurrency, and were able to scale using fewer servers as a result, as opposed to just throwing general-purpose java/.net and more servers at the problem. Just another example of right tool for the job.
Re: Lost a new commercial user this week :(
On 12/14/14, Kiith-Sa via Digitalmars-d digitalmars-d@puremagic.com wrote:
Example:
ptrdiff_t countUntil(alias pred = a == b, R, Rs...)(R haystack,
Rs needles) if (isForwardRange!R Rs.length 0
isForwardRange!(Rs[0]) == isInputRange!(Rs[0])
is(typeof(startsWith!pred(haystack, needles[0]))) (Rs.length
== 1 || is(typeof(countUntil!pred(haystack, needles[1..$]);
ptrdiff_t countUntil(alias pred = a == b, R, N)(R haystack, N
needle) if (isInputRange!R
is(typeof(binaryFun!pred(haystack.front, needle)) : bool));
Yeah, this is still a problem even if you're experienced with
templates. It's a wall of text.
It seems like we're treating template constraints as an internal
feature (just to use them to limit the possible arguments or allow
overloading against other templates), but I think constraints should
also be looked at as a source of documentation (Can I call this
template with this argument type? Let's see the constraint.. Whoa this
is complicated..).
CSS trickery might work, but I'd prefer if we didn't beat around the
bush and instead implemented constraits as separate templates if they
become too complicated, e.g. turn the above to:
ptrdiff_t countUntil(alias pred = a == b, R, Rs...)(R haystack,
Rs needles) if (canCountUntil!(pred, R, Rs);
And then the canCountUntil template would be separately documented,
something like:
/** A range can be counted if:
- R is a forward range
- pred is a valid string comparison predicate, or a function that can
compare R.front with Rs.front
- ...
*/
template canCountUntil(alias pred, R, Rs...)
{
...
}
I mean the predicate itself kind of documents this, but it's very
unreadable despite the logic making sense.
We already have things like isInputRange, and functions with
constraints would likely look horrible if we copy-pasted the
isInputRange implementation directly into their constraints rather
than use a simple isInputRange!R check. In the same fashion the
countUntil (and other functions with complex constraints) should have
a helper template that's used as a constraint (like I've shown above).
Re: Lost a new commercial user this week :(
On Sunday, 14 December 2014 at 15:36:47 UTC, yawniek wrote: On Sunday, 14 December 2014 at 14:09:57 UTC, Joakim wrote: As always, different tools for different uses. Hopefully, D can one day be polished and mainstream enough for the enterprise use case and it will be efficient enough to be deployed at scale too. :) when will that be? windows version 25, sqlite version 1147? ...[snip]... Perhaps when more people start helping out we'll see things progress more quickly. D needs more than developers. Right now it needs a few volunteers who will update the web site; documentation, news feeds of recent PRs closed, recent PRs that are generating interesting discussion, roadmaps for the next 12 months indicating what core devs are working and status. Stuff that get's people excited about the next release and the future of D. Cheers, uri
Re: DIP69 - Implement scope for escape proof references
On 12/13/2014 4:44 PM, Manu via Digitalmars-d wrote: On 13 December 2014 at 15:11, Walter Bright via Digitalmars-d digitalmars-d@puremagic.com wrote: On 12/12/2014 6:55 PM, Manu via Digitalmars-d wrote: I did just give some examples, I'll repeat; auto ref fails when the function is extern. Don't make it extern, then. Do you think I just interact with other languages for fun or something? I'm not trying to insult you - but why need 'auto ref' for extern functions? The extern functions are ref or not-ref, and declare the interface to match. There's no point to auto ref there. If there's source to the function, it'll often be inlined which will remove the indirection. Not if it's extern (applicable to ref, not auto-ref), or wrapped, or if I ever want to capture a function pointer. It's also semantically different; I can change the caller's value. Again, if it is extern it has a fixed definition of ref or not. The D side doesn't decide if it's ref or not, it just follows whatever the extern declaration is. This is why I do not understand why you are running into this issue everywhere. What do you get when you take a pointer of a function with an auto-ref arg? ...an error, because it's not actually a function! So in a context where I'm dealing with functions and function pointers (very, very frequent), I suddenly have something that's not a function find it's way into my meta and I have to special-case the hell out of it. Why are function pointers and ints going to the same argument of a function? I thought you weren't using templates? I'm confused. I'm talking about capturing function pointers. Not about function arguments. Capturing pointers of functions with auto-ref args (aka, template functions) is a serious nuisance, and impossible outside the site of instantiation. WHY are you doing this? I have no idea what coding pattern would need to pass functions by reference. I wonder what is the need for the code that you are writing. General function adaptation. There are lots of reasons to wrap functions. Adaptation to existing or external API's is the most common in my experience. Are those API's all templated? My guess is no. If they're not, you don't need templates or auto-ref to interface to them. Functions are what programs are! I really struggle to understand why you have such trouble sympathising with my view here. Because you don't provide any examples of why you need this stuff. You say I need this feature because I'm doing X, but I have no idea what X is or why you need X. I.e. you present and advocate for particular solutions, but not the problems. Languages generate code, which is packaged into blocks we call 'functions'... and they require to adhere to strict ABI requirements. That is programming in a nutshell. Surely it's reasonable to want to retain complete control over this most primitive and basic of tasks. One important aspect of that control is where the code is generated; is it 'here', or 'there'? Why is that important? And that's a critical distinction between functions and templates. You can control that with function templates, too. The compiler won't instantiate a template locally if the import instantiates it. Look at LuaD. Lots of awkward cases have emerged there. There are many more to come too; the known bug list are mostly nasty issues of this nature that I've been putting off. I can't offer any insight into my commercial code sadly, and I no longer have access to it :/ Situations like this appear frequently: https://github.com/JakobOvrum/LuaD/pull/76/files#diff-bcb370a5bc6fe75a9d5c04f2e1c17eb0R178 And something like this tends to appear as one aspect of the solution: https://github.com/JakobOvrum/LuaD/pull/76/files#diff-bcb370a5bc6fe75a9d5c04f2e1c17eb0R68 'struct Ref(T)' leads to its own problems though, in that it's a localised concept. No external code anywhere understands it as a 'ref', so if 3rd party code has any special treatment for ref, that code now fails. Then more magic like this: https://github.com/JakobOvrum/LuaD/pull/76/files#diff-ec8c532aeca798240de4d70ee639fc16R90 Since we need to recognise 'ref' and substitute it for our magic 'struct Ref(T)'. I've probably spent more hours wrangling D meta of this sort than most people. This sort of thing always happens. If Ref!T is the tool that resolves the situation, then it's clear demonstration that ref should be part of the type. I'll take a look at your references in a moment. When I'm writing a function that's not a template, I intend, and expect, to write a function that's _not a template_. Templates and functions are different things. I think it's a massive mistake to have created a way to write a template that looks nothing like a template. A function template is a function that takes both compile-time args and run-time args. C++ tried to make them completely different animals, when they are not. Don't think template, think compile-time
Re: Why do you write D2 compiler using C++ language?
On Sunday, 14 December 2014 at 16:44:09 UTC, ddj wrote: On Saturday, 13 December 2014 at 23:02:52 UTC, Mike Parker wrote: On 12/13/2014 10:55 PM, ddj wrote: But so many issues and bug fixes scares me from using it. That's just the wrong way to look at it. Take a look at the bug list for gcc, any of the Java compilers, or clang. Are you afraid to use them as well? Maybe, but gcc and java compilers have long history of stable releases and many programs and libraries written. Clang has standards to implement and! static analyzer. As Mike said, look at the bug tracker history for these projects. Even with all those stable releases there were always lots of open bugs and today in GCC 4.9 there are issues: http://lkml.iu.edu//hypermail/linux/kernel/1407.3/00650.html We use GCC 4.8 at my work where we develop class II and class III health-care devices - A life support system is class III...how well do you trust GCC? :-). Joking aside we design for failure and have a 4 year verification process that weeds out critical bugs in our code and the compiler. Cheers, uri
Re: Lost a new commercial user this week :(
On 12/14/2014 2:59 PM, Andrej Mitrovic via Digitalmars-d wrote: CSS trickery might work, but I'd prefer if we didn't beat around the bush and instead implemented constraits as separate templates if they become too complicated, e.g. turn the above to: I think this is a fine idea.
Re: Lost a new commercial user this week :(
On Sunday, 14 December 2014 at 08:37:36 UTC, Manu via Digitalmars-d wrote: We were trying to use vibe.d, and we encountered bugs. We were unable to build Win64 code ... Here is exactly your problem - trying to do a web development on Windows :P Really I have never understood that counter-productive obsession with a habit that makes people differentiate development environments and production environments so much. You aren't going to use Windows servers, are you? Well, that was somewhat off-topic grumpy remark. On actual marketing thing: In my opinion biggest evangelist mistake everyone makes it trying to advertise D for something it simply isn't. Which inevitably fails and leaves people extremely frustrated with false advertising, like to remain there forever as a prejudice against D. Because you will have a better luck torturing kittens than try false advertising and get caught. Idea that any D project can compete with node.js in easy to jump in domain is absolutely ridiculous. Attempting this is just dooming yourself to fail. Same is trying to advertise it is stable mature language - reality is it is simply not true and people will find out it sooner or later. I think trying to sell D should look something like this Yes, D is horrible because of X, Y and Z but here is why it doesn't matter for our case : A, B and C. Don't pretend perfection but explain trade-offs. You won't beat node.js in getting started curve. You won't beat Java in designing huge complex systems (well, at least everyone says that). You won't beat C in raw low-level performance. But D will easily beat C in getting started curve and complex design, easily beat node.js in performance and complex design and (not-so-easily) beat Java in performance and overall versatility. Remember the talk by Stephan (http://dconf.org/2014/talks/dilly.html) about their vibe.d usage in production and points he has made when comparing vs node.js? It was about performance, it was about resource overhead, it was about benefits of static type system and horrors of callback hell. It wasn't about how vibe.d is more shiny than node.js - and it was good. If your colleagues went with node in the end and kept happy with it, quite likely they simple don't need advantages vibe.d can give to their project. There is no shame in it.
Re: Lost a new commercial user this week :(
On 12/14/2014 5:29 PM, Dicebot wrote: If your colleagues went with node in the end and kept happy with it, quite likely they simple don't need advantages vibe.d can give to their project. There is no shame in it. I also noted that none of the issues were the language itself.
Re: DIP69 - Implement scope for escape proof references
On Saturday, 13 December 2014 at 00:10:07 UTC, Walter Bright wrote: The proposal provides escape proof passing of arguments. This is necessary in order to make rc safe, for example. What are you looking for? I am looking for a tool to prevent escaping references to user-defined entities / resources from specific scope. RC case is not interesting at all to me though I recognize the potential benefits of tweaking the scope system to help with it. But there is a big difference between tweak for one specific use case or designing feature around it (so it becomes almost useless in other cases). I have already provided you an example of code I want to be enforced with scope and two major issues with existing proposal that make it lacking. This example is akin to litmus test for any scope proposal - if it doesn't allow to express such design, that proposal is simply not good enough. In case you have forgotten, I am reminding about two critical points that are necessary to make it fly: 1) inout analog for scope to be able to deduce borrowship of return values based on borrowship of input arguments. Current system is conservative and results in template bloat (complicated by the fact that it is storage class thus not actually part of a type) 2) at least optional transitivity to be able to express to protect with scope data referenced by slice or owned linked list referenced from root node. -- In your tree example I would have never wanted scope protection of one specific node of such tree - but a transitive scope protection of whole tree view available through on of node pointers/references. It doesn't matter who and how owns the data for borrowship implementation - only thing that matters that _it is not me_.
Re: i want my bounty!
ketmar via Digitalmars-d wrote in message news:mailman.3160.1418550079.9932.digitalmar...@puremagic.com... but talking seriously, i don't need any bounty, i just want somebody to take a look at that and either tell me what to fix or integrate it in mainline. along with this one: https://issues.dlang.org/show_bug.cgi?id=13526 Review of patches for dmd are done on github: http://wiki.dlang.org/Pull_Requests#Create_a_pull_request
Re: DIP69 - Implement scope for escape proof references
On 12/14/2014 5:44 PM, Dicebot wrote: I am looking for a tool to prevent escaping references to user-defined entities / resources from specific scope. RC case is not interesting at all to me though I recognize the potential benefits of tweaking the scope system to help with it. But there is a big difference between tweak for one specific use case or designing feature around it (so it becomes almost useless in other cases). I have already provided you an example of code I want to be enforced with scope and two major issues with existing proposal that make it lacking. This example is akin to litmus test for any scope proposal - if it doesn't allow to express such design, that proposal is simply not good enough. In case you have forgotten, I am reminding about two critical points that are necessary to make it fly: 1) inout analog for scope to be able to deduce borrowship of return values based on borrowship of input arguments. Current system is conservative and results in template bloat (complicated by the fact that it is storage class thus not actually part of a type) 1. All inout actually does is reduce code copy/pasta, it is not critical. 2. This is what scope inference is all about. 2) at least optional transitivity to be able to express to protect with scope data referenced by slice or owned linked list referenced from root node. 1. that won't work unless scope is a type constructor 2. it can be achieved by using wrappers that only allow by-scope references to their data (RC is an example of such a wrapper) In your tree example I would have never wanted scope protection of one specific node of such tree - but a transitive scope protection of whole tree view available through on of node pointers/references. It doesn't matter who and how owns the data for borrowship implementation - only thing that matters that _it is not me_. As I explained to Manu, transitive scope makes things like doing a symbol table lookup, then putting a pointer to the found symbol in an AST, not workable.
Re: DIP69 - Implement scope for escape proof references
On Monday, 15 December 2014 at 02:45:04 UTC, Walter Bright wrote: 1. All inout actually does is reduce code copy/pasta, it is not critical. Being forced to duplicate every single function in two flavors to actually make scope system usable? This is as much critical as it can be. 2. This is what scope inference is all about. Which only works with templates and lack of scope on arguments does not affect function body - templates are not necessary, same as inout. 2) at least optional transitivity to be able to express to protect with scope data referenced by slice or owned linked list referenced from root node. 1. that won't work unless scope is a type constructor I know and this is why I am leaning toward it being qualifier despite all related issues. 2. it can be achieved by using wrappers that only allow by-scope references to their data (RC is an example of such a wrapper) It is viral approach and backwards incompatible one - we can't change signatures of Phobos functions to return Wrapped!(char[]) instead of char[] for example. While theoretically possible I can't call this approach practical - not until see some convincing application example. In your tree example I would have never wanted scope protection of one specific node of such tree - but a transitive scope protection of whole tree view available through on of node pointers/references. It doesn't matter who and how owns the data for borrowship implementation - only thing that matters that _it is not me_. As I explained to Manu, transitive scope makes things like doing a symbol table lookup, then putting a pointer to the found symbol in an AST, not workable. This sounds totally against my understanding of scope. I want scope exactly to prohibit such actions. However it is possible in slightly modified way - where you don't directly insert pointer to AST but use public method of AST control structure that checks if supplied scope pointer belongs to list of nodes it owns and casts away scope after that.
Re: Caller of dynamic library crashes with SIGSEV if D code allocates anything on heap.
The current issue is if I build a dynamic library with DUB and call externals form another application, and my D code allocates anything on heap, the calling process crashes with SIGSEV. Don't forget to link against libphobos2.so using -defaultlib=libphobos2.so.
Re: Lost a new commercial user this week :(
On 12/14/2014 09:37 AM, Manu via Digitalmars-d wrote: The real trouble hit when vibe.d's WebSocket support didn't work as advertised; it crashed in various circumstances, and debugging was impossible. Please file that one https://github.com/rejectedsoftware/vibe.d/issues. What browser did you use?
Re: Lost a new commercial user this week :(
On 12/14/2014 09:37 AM, Manu via Digitalmars-d wrote: Sadly, I failed to create a new commercial D user this week, and I'm really disappointed. It was rejected for exactly the same practical reasons I've been saying forever. Doesn't surprise me too much to be honest. We aren't there yet and I'm always a bit uneasy when someone runs around advertising D to professional users.
Re: Adding DMDScript to dub
On 12/13/2014 02:53 AM, Walter Bright wrote: Dmitry Olshansky has graciously ported DMDScript (a Javascript engine written in D) to D2. https://github.com/DigitalMars/DMDScript I have been trying to get it into dub, but have been stalled by the following when I attempt to register: Repository owner: DigitalMars Repository name: DMDScript it says in red: Package names may not be empty. Check dub.json. What does that mean? There is no package name field in the dub.json file. You should the full error, it says. Branch ~test: Package names may not be empty. Check dub.json.
Re: Lost a new commercial user this week :(
On 15 December 2014 at 07:19, Nick B via Digitalmars-d digitalmars-d@puremagic.com wrote: On Sunday, 14 December 2014 at 15:03:27 UTC, Sönke Ludwig wrote: Lastly, when judging all these things, please always try to remember that almost all the work that goes into D (and vibe.d) is non-profit and everyone usually only contributes what (s)he is missing. If I would get payed through a support contract for my work on vibe.d, I could adjust my priorities to suit the requirements of others more, but like this I still have to somehow make sure to be able to pay my bills and can't just work full time to help other (commercial) projects (although I always try to help as far as possible). Sonke, Can you advise how much a support contract for a individual or company seriously interested in using vibe.d might cost ? Good point, I think you should really put a price on commercial support if you want it to be taken seriously. There are lots of companies that wouldn't seriously consider it if it DIDN'T cost them some money. If they don't pay any money, it doesn't look legit or professional ;)
Re: Adding DMDScript to dub
On 12/14/2014 8:53 PM, Martin Nowak wrote: On 12/13/2014 02:53 AM, Walter Bright wrote: Dmitry Olshansky has graciously ported DMDScript (a Javascript engine written in D) to D2. https://github.com/DigitalMars/DMDScript I have been trying to get it into dub, but have been stalled by the following when I attempt to register: Repository owner: DigitalMars Repository name: DMDScript it says in red: Package names may not be empty. Check dub.json. What does that mean? There is no package name field in the dub.json file. You should the full error, it says. Branch ~test: Package names may not be empty. Check dub.json. That's a new error, I fixed the original per Rikki's advice. I don't understand it, either. Shouldn't it be looking at master, not branch test?
Re: DIP69 - Implement scope for escape proof references
On 12/14/2014 7:41 PM, Dicebot wrote: On Monday, 15 December 2014 at 02:45:04 UTC, Walter Bright wrote: 1. All inout actually does is reduce code copy/pasta, it is not critical. Being forced to duplicate every single function in two flavors to actually make scope system usable? This is as much critical as it can be. C++ seems to do fine without it for const. It's a convenience feature. 2. This is what scope inference is all about. Which only works with templates and lack of scope on arguments does not affect function body - templates are not necessary, same as inout. It also works with all the lambdas, since source for them is always available. I also wanted to make it (i.e. inference) work with auto functions, but Don Clugston was the primary objector :-) I do view inference as something we need to extend to more functions. 2) at least optional transitivity to be able to express to protect with scope data referenced by slice or owned linked list referenced from root node. 1. that won't work unless scope is a type constructor I know and this is why I am leaning toward it being qualifier despite all related issues. That would be a truly massive change to D, and I'm not at all sure it would be worth it. We've (i.e. Kenji) have been fixing bugs with inout for years, and idea that had seemed straightforward. 2. it can be achieved by using wrappers that only allow by-scope references to their data (RC is an example of such a wrapper) It is viral approach and backwards incompatible one - we can't change signatures of Phobos functions to return Wrapped!(char[]) instead of char[] for example. While theoretically possible I can't call this approach practical - not until see some convincing application example. But you can change signatures to add annotations? You're going to get one or the other. This sounds totally against my understanding of scope. I want scope exactly to prohibit such actions. However it is possible in slightly modified way - where you don't directly insert pointer to AST but use public method of AST control structure that checks if supplied scope pointer belongs to list of nodes it owns and casts away scope after that. Wrappers do that, too. I know that 'wrapper' sounds bad to you, but one of the goals of D's UDT's is to make it easy to adapt the behavior of a type by wrapping it in a struct, rather than build new behavior into the language.
Re: Lost a new commercial user this week :(
On 12/14/2014 9:10 PM, Manu via Digitalmars-d wrote: On 15 December 2014 at 07:19, Nick B via Digitalmars-d digitalmars-d@puremagic.com wrote: Sonke, Can you advise how much a support contract for a individual or company seriously interested in using vibe.d might cost ? Good point, I think you should really put a price on commercial support if you want it to be taken seriously. There are lots of companies that wouldn't seriously consider it if it DIDN'T cost them some money. If they don't pay any money, it doesn't look legit or professional ;) It does look like a great opportunity for Sönke! He gets paid, vibe.d gets better, the community gets another commercial user, it's a win all around! (Of course, that applies to all of you folks working on open source D code - think about doing contract support for it.)
Re: Adding DMDScript to dub
On 15/12/2014 7:12 p.m., Walter Bright wrote: On 12/14/2014 8:53 PM, Martin Nowak wrote: On 12/13/2014 02:53 AM, Walter Bright wrote: Dmitry Olshansky has graciously ported DMDScript (a Javascript engine written in D) to D2. https://github.com/DigitalMars/DMDScript I have been trying to get it into dub, but have been stalled by the following when I attempt to register: Repository owner: DigitalMars Repository name: DMDScript it says in red: Package names may not be empty. Check dub.json. What does that mean? There is no package name field in the dub.json file. You should the full error, it says. Branch ~test: Package names may not be empty. Check dub.json. That's a new error, I fixed the original per Rikki's advice. I don't understand it, either. Shouldn't it be looking at master, not branch test? Test branch: https://github.com/DigitalMars/DMDScript/blob/test/dub.json Master branch: https://github.com/DigitalMars/DMDScript/blob/test/dub.json Same issue, just hasn't been updated.
Re: Lost a new commercial user this week :(
On Sunday, 14 December 2014 at 15:03:27 UTC, Sönke Ludwig wrote: snip / Lastly, when judging all these things, please always try to remember that almost all the work that goes into D (and vibe.d) is non-profit and everyone usually only contributes what (s)he is missing. If I would get payed through a support contract for my work on vibe.d, I could adjust my priorities to suit the requirements of others more, but like this I still have to somehow make sure to be able to pay my bills and can't just work full time to help other (commercial) projects (although I always try to help as far as possible). Sönke How about adding a support section to vibed.org with possible support options you could consider? :-)
Re: Lost a new commercial user this week :(
On Sunday, 14 December 2014 at 21:00:13 UTC, Kiith-Sa wrote: On Sunday, 14 December 2014 at 19:40:16 UTC, Walter Bright wrote: snip / One thing I ran into often when I was inexperienced with D: the template constraints make some signatures extremely messy, and it takes a while to figure out when you have e.g. 3 template functions of the same name in std.algorithm, all with crypric signatures. snip / Super nice idea! Create a PR for this?
Re: Lost a new commercial user this week :(
On Sunday, 14 December 2014 at 23:25:24 UTC, uri wrote: On Sunday, 14 December 2014 at 15:36:47 UTC, yawniek wrote: On Sunday, 14 December 2014 at 14:09:57 UTC, Joakim wrote: As always, different tools for different uses. Hopefully, D can one day be polished and mainstream enough for the enterprise use case and it will be efficient enough to be deployed at scale too. :) when will that be? windows version 25, sqlite version 1147? ...[snip]... Perhaps when more people start helping out we'll see things progress more quickly. D needs more than developers. Right now it needs a few volunteers who will update the web site; documentation, news feeds of recent PRs closed, recent PRs that are generating interesting discussion, roadmaps for the next 12 months indicating what core devs are working and status. Stuff that get's people excited about the next release and the future of D. Cheers, uri Speaking of getting more people involve. There are some great suggestions in this reddit thread and in the linked article: https://www.reddit.com/r/programming/comments/2p9ff3/how_to_get_started_with_open_source/
Re: Lost a new commercial user this week :(
On 15/12/2014 8:14 p.m., NVolcz wrote: On Sunday, 14 December 2014 at 23:25:24 UTC, uri wrote: On Sunday, 14 December 2014 at 15:36:47 UTC, yawniek wrote: On Sunday, 14 December 2014 at 14:09:57 UTC, Joakim wrote: As always, different tools for different uses. Hopefully, D can one day be polished and mainstream enough for the enterprise use case and it will be efficient enough to be deployed at scale too. :) when will that be? windows version 25, sqlite version 1147? ...[snip]... Perhaps when more people start helping out we'll see things progress more quickly. D needs more than developers. Right now it needs a few volunteers who will update the web site; documentation, news feeds of recent PRs closed, recent PRs that are generating interesting discussion, roadmaps for the next 12 months indicating what core devs are working and status. Stuff that get's people excited about the next release and the future of D. Cheers, uri Speaking of getting more people involve. There are some great suggestions in this reddit thread and in the linked article: https://www.reddit.com/r/programming/comments/2p9ff3/how_to_get_started_with_open_source/ For reference http://openhatch.org/ has no D projects.
Re: Lost a new commercial user this week :(
On Monday, 15 December 2014 at 01:30:00 UTC, Dicebot wrote: On Sunday, 14 December 2014 at 08:37:36 UTC, Manu via Digitalmars-d wrote: We were trying to use vibe.d, and we encountered bugs. We were unable to build Win64 code ... Here is exactly your problem - trying to do a web development on Windows :P Really I have never understood that counter-productive obsession with a habit that makes people differentiate development environments and production environments so much. You aren't going to use Windows servers, are you? Well, lots of Fortune 500 companies do. If you want to appeal to those users, D has to be better than the whole .NET eco-system, specially now that static binaries are going to be supported as well. Not to mention the C++ tooling which is just great. -- Paulo
Re: Adding DMDScript to dub
On 12/14/2014 10:21 PM, Rikki Cattermole wrote: On 15/12/2014 7:12 p.m., Walter Bright wrote: Branch ~test: Package names may not be empty. Check dub.json. That's a new error, I fixed the original per Rikki's advice. I don't understand it, either. Shouldn't it be looking at master, not branch test? Test branch: https://github.com/DigitalMars/DMDScript/blob/test/dub.json Master branch: https://github.com/DigitalMars/DMDScript/blob/test/dub.json Same issue, just hasn't been updated. How do I get dub to stop looking at the test branch?
Re: Why do you write D2 compiler using C++ language?
On Monday, 15 December 2014 at 00:58:29 UTC, uri wrote: On Sunday, 14 December 2014 at 16:44:09 UTC, ddj wrote: On Saturday, 13 December 2014 at 23:02:52 UTC, Mike Parker wrote: On 12/13/2014 10:55 PM, ddj wrote: But so many issues and bug fixes scares me from using it. That's just the wrong way to look at it. Take a look at the bug list for gcc, any of the Java compilers, or clang. Are you afraid to use them as well? Maybe, but gcc and java compilers have long history of stable releases and many programs and libraries written. Clang has standards to implement and! static analyzer. As Mike said, look at the bug tracker history for these projects. Even with all those stable releases there were always lots of open bugs and today in GCC 4.9 there are issues: http://lkml.iu.edu//hypermail/linux/kernel/1407.3/00650.html We use GCC 4.8 at my work where we develop class II and class III health-care devices - A life support system is class III...how well do you trust GCC? :-). Joking aside we design for failure and have a 4 year verification process that weeds out critical bugs in our code and the compiler. Cheers, uri Aren't you using certified compilers? It was my understanding that for life support systems only certified compilers are allowed. .. Paulo
Re: std.array oddness
On Sun, 14 Dec 2014 05:15:43 + earthfront via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: On Saturday, 13 December 2014 at 06:40:41 UTC, ketmar via Digitalmars-d-learn wrote: auto names = File(names.txt) .byLine!(char,char)(KeepTerminator.no, ',') .map!a.idup .array; Awesome. map!idup does the trick. I had looked at the byLine doc before posting, in particular, this line: Note: Each front will not persist after popFront is called, so the caller must copy its contents (e.g. by calling to!string) if retention is needed. This explains the behavior though I didn't get it then. It's talking about the range methods. Following the component based stuff from Walter's article can be brain-bendy. And in this case, requires careful reading of the docs. But I like it. it's a matter of time to become used with that ranges stuff. but then you will start seeing ranges everywhere. ;-) signature.asc Description: PGP signature
Re: dub dustmite
On Friday, 12 December 2014 at 04:25:01 UTC, Vlad Levenfeld wrote: I'm trying to reduce a bug with dub dustmite feature and I must be doing it wrong somehow, my regular dub output looks like this: source/experimental.d(2403): Error: struct experimental.Product!(int[], int[]).Product no size yet for forward reference ulong[2] source/experimental.d(2454): Error: template instance experimental.Product!(int[], int[]) error instantiating source/experimental.d(2462):instantiated from here: by!(int[], int[]) FAIL .dub/build/application-debug-linux.posix-x86_64-dmd_2067-44246AA2375AB6C7D895600135F734E4/ engine_vx executable Error executing command run: dmd failed with exit code 1. and then when I run this command dub dustmite ~/dubdust --compiler-regex=Product no size yet I get Executing dustmite... None = No object.Exception@dustmite.d(243): Initial test fails It seems like a pretty simple case, I'm not sure what's going on. Try using --combined. This will test all packages at the same time if you have dependencies.
Re: How to share modules when using -shared?
On Wednesday, 10 December 2014 at 00:44:41 UTC, Justin Whear wrote: I'm trying to build components that I can dynamically link and keep running into an issue with sharing modules between the host and the pluggable components. Assuming a layout like this: host.d -- loads components at runtime a.d -- a module that builds to `a.so` b.d -- a module that builds to `b.so` common.d If a.d and b.d both import common.d, all is well. If host.d imports common.d as well, I get this at runtime: Fatal Error while loading 'a.so': The module 'common' is already defined in 'host'. Test session with sources here: http://pastebin.com/LxsqHhJm Some of this can be worked around by having host.d use its own extern definitions, but how does this work with interfaces? My tests thus far have resulted in object invariant failures. You can have common in separate .so file, or include it in host.
