Re: DConf Artwork now public and released under Creative Commons
On Tuesday, 6 February 2018 at 11:39:33 UTC, Seb wrote: [snip] And of course the very friendly people from Sociomantic (Shai Tayeb, Leandro Lucarella, and Dylan Cromwell et.al.) who put a lot of effort into making the last DConfs and its related artwork happen. Thanks!!! Thanks for putting this together in GitHub! I don't deserve much credit, but I'd like to thank Thomas "Tom" Nikolai, one of the Sociomantic founder without whom DConf would probably never happened in Berlin (at least organized by Sociomantic). Once when discussing about sending people to DConf he said something along the lines of "Fuck it! Instead of sending people why don't we make everybody else come to Berlin?". And that's how the idea was born :-)
Re: Release D 2.078.0
On Wednesday, 10 January 2018 at 05:35:05 UTC, Andre Pany wrote: On Wednesday, 3 January 2018 at 17:43:36 UTC, Martin Nowak wrote: Glad to announce D 2.078.0. This release comes with runtime detection of Visual Studio installation paths, an integral promotion transition for unary operations on byte and short sized integers, more -betterC features, and a couple of language and library tweaks. Thanks to everyone involved in this https://dlang.org/contributors.html. http://downloads.dlang.org/releases/2.x/2.078.0/ http://dlang.org/changelog/2.078.0.html - -Martin What is the purpose of the coverage option "srcpath"? In my scenario I have a folder "dependencies" and a folder "source". I want to generate code coverage only for the files in folder "source". dmd -unittest -cov source/app.d dependencies/dep.d app.exe --DRT-covopt="srcpath:./source dstpath:./cov" By specifying "srcpath" there are 2 empty files created in folder cov: source-app.lst dependencies-dep.lst I thought by specifying "srcpath" I limit the code coverage generation to the files located in folder source... From what I saw in the code, I think what it does is just override where the code was actually placed when you compiled, so tools to visualize the coverage can show you the source code. * https://dlang.org/code_coverage.html#switchsrcpath * https://github.com/dlang/druntime/blob/382b759738b5fa1e59bfda2ad542b9d60ef3d59a/src/rt/cover.d#L83-L84 * https://github.com/dlang/druntime/blob/382b759738b5fa1e59bfda2ad542b9d60ef3d59a/src/rt/cover.d#L211 BTW, to just report coverage of certain files you can just compile with `-cov` those files. I guess that should work (maybe? :).
Re: Ocean v3.0.0: First fully public release!
On Monday, 13 March 2017 at 11:33:42 UTC, Nicholas Wilson wrote: On Monday, 13 March 2017 at 11:08:51 UTC, Leandro Lucarella wrote: On Friday, 10 March 2017 at 16:31:53 UTC, Andrea Fontana wrote: On Friday, 10 March 2017 at 15:19:51 UTC, Leandro Lucarella wrote: Hi dear D community! We wanted to share with you some nice news and big milestone: we are (finally!) going completely public with Ocean development! From github page: General purpose, platform-dependant, high-performance library for D You missed it :) I don't get this. What did I miss exactly? :) Your OP doesn't say what Ocean does. Right, the library itself was announced a long time ago here but maybe I shouldn't assume people in this forum don't change (and it has good memory, I know I don't :D). Extended description, in case is useful: Ocean is a general purpose library, compatible with both D1 and D2, with a focus on supporting the development of high-performance, real-time applications. This focus has led to several noteworthy design choices: * Ocean is not cross-platform. The only supported platform is Linux. * Ocean assumes a single-threaded environment. Fiber-based multi-tasking is favoured, internally. * Ocean aims to minimise use of the D garbage collector. GC collect cycles can be very disruptive to real-time applications, so Ocean favours a model of allocating resources once then reusing them, wherever possible. Ocean began life as an extension of Tango, some elements of which were eventually merged into Ocean.
Re: Ocean v3.0.0: First fully public release!
On Friday, 10 March 2017 at 16:31:53 UTC, Andrea Fontana wrote: On Friday, 10 March 2017 at 15:19:51 UTC, Leandro Lucarella wrote: Hi dear D community! We wanted to share with you some nice news and big milestone: we are (finally!) going completely public with Ocean development! From github page: General purpose, platform-dependant, high-performance library for D You missed it :) I don't get this. What did I miss exactly? :)
Ocean v3.0.0: First fully public release!
Hi dear D community! We wanted to share with you some nice news and big milestone: we are (finally!) going completely public with Ocean development! Starting with the new v3.0.0 release all the development done to the library will go to the public repository (and actually this goes too for the older versions still in maintenance mode, v2.5.x and v2.6.x at the time, and in development mode, v2.x.x). No more internal development and sync points from time to time. Because of this you should start seeing a *LOT* more activity on the project from now on, and we encourage the community to once again have a look at it. Standard disclaimer: to be used with D2 there still an automatic conversion step that needs to be done, and you'll need a slightly older and modified dmd, but we were (are?) working on that too with Walter / Andrei / Martin on how we can push for the changes we need in D2 to be able to use the vanilla compiler. I won't bother you with the changelog for v3.0.0 (is packed with more than a dozen of new features, the release notes themselves are about 200 lines long :D), but if you are curious you can have a look at it: https://github.com/sociomantic-tsunami/ocean/releases/tag/v3.0.0 Contributions are more welcome than ever. Happy hacking!
Ocean v2.1.1 released
Hello dlang-forum-people! After almost 3 months since the open sourcing of Ocean, I wanted to give a small project update. Yesterday both Ocean v2.1.0 and the patch release v2.1.1 were released. This is first minor public release since the open sourcing. Minor releases include new features, and since v2.1.0 consists on the merging of 2 minor releases in our v1.x.x internal branch, it is packed with quite a few new stuff. You can see the full changelog(s) here: https://github.com/sociomantic-tsunami/ocean/releases/tag/v2.1.0-preview https://github.com/sociomantic-tsunami/ocean/releases/tag/v2.1.1-preview In the meantime, we also did 8 maintenance releases for the v2.0 series (most containing only 1 bug fix, but some containing almost up to 10): https://github.com/sociomantic-tsunami/ocean/releases/tag/v2.0.1-preview https://github.com/sociomantic-tsunami/ocean/releases/tag/v2.0.2-preview https://github.com/sociomantic-tsunami/ocean/releases/tag/v2.0.3-preview https://github.com/sociomantic-tsunami/ocean/releases/tag/v2.0.4-preview https://github.com/sociomantic-tsunami/ocean/releases/tag/v2.0.5-preview https://github.com/sociomantic-tsunami/ocean/releases/tag/v2.0.6-preview https://github.com/sociomantic-tsunami/ocean/releases/tag/v2.0.7-preview https://github.com/sociomantic-tsunami/ocean/releases/tag/v2.0.8-preview All this is in the good side. On the bad side, we still couldn't move the whole development to the open source project (the main blocker still being setting up automated testing for the open source project), so for the v2.1.0 release we just included all the changes as a big commit instead of porting all the individual commits we made in our internal project. This is just a temporary, transitional issue, though and patch releases still get the commits cherry picked properly, as it is much easier than with full minor releases :) All that said, I want to clarify again, that the `-preview` mark doesn't really mean this is not production ready, is the exact same code we are using internally at Sociomantic, is just that we want to make clear that development is still not fully moved to the open source project and also having different tags for the internal and external releases makes maintaining both a bit easier for now. Finally, I would love to hear if somebody is using, or have used or adapted any code in Ocean. Thanks!
Re: daffodil, a D image processing library
On Thursday, 30 June 2016 at 21:35:37 UTC, Benjamin Schaaf wrote: Alongside I've also written (an admittedly hacky) sphinx (http://www.sphinx-doc.org/en/stable/) extension that provides a domain and autodocumenter for D, using libdparse and pyd. Where can I get the Sphinx extension? :-D
Re: Ocean preview finally open sourced
On Friday, 1 July 2016 at 09:43:53 UTC, Ola Fosheim Grøstad wrote: On Thursday, 30 June 2016 at 16:45:43 UTC, Leandro Lucarella wrote: (although please have a look at the licensing terms, even when all our code is Boost, there is code inherited from Tango that isn't), criticize it, and if you are really nice, fill issues and make pull requests! I find the licensing a bit confusing. For instance https://github.com/sociomantic-tsunami/ocean/blob/v2.x.x/src/ocean/math/Probability.d Lists the licensing as: Tango 3 BSD Clause + Academic Free License v3.0. But the original work Cephes seems to carry this ad-hoc license: https://github.com/jeremybarnes/cephes/blob/master/readme Oh, well. Sorting out the license(s) were one of the major pains and time consuming tasks we had to do to opensource this, and apparently despite our best efforts there are stuff that we didn't see. This comes from Tango, so we kept the original Tango license. I would assume Tango people did a check on this, and had some sort of permission to change the license, but I will try to contact the author to make sure this is the case. If not, then we'll probably remove that module (we removed a lot of Tango modules because of dubious origin/license already). https://github.com/sociomantic-tsunami/ocean/issues/2 « Some software in this archive may be from the book _Methods and Programs for Mathematical Functions_ (Prentice-Hall or Simon & Schuster International, 1989) or from the Cephes Mathematical Library, a commercial product. In either event, it is copyrighted by the author. What you see here may be used freely but it comes with no support or guarantee. The two known misprints in the book are repaired here in the source listings for the gamma function and the incomplete beta integral. » Maybe it would be a good idea to sort out the code that is pure Boost, or obtain a boost license where the authors are known, because complicated licensing is a hindrance even if the "spirit" is the same across the licenses. We know that, and again, the license was by far the biggest nightmare of the open sourcing effort. Honestly we don't have the time to take on this, but this is an area where external contributions would be extremely helpful. Anyone can contact the original authors and ask for permission (although to make sure we probably need to check the full Tango history to see all the people that actually contributed, sometimes the Authors section is quite bogus).
Re: Ocean preview finally open sourced
On Friday, 1 July 2016 at 09:13:46 UTC, Chris wrote: On Friday, 1 July 2016 at 08:54:27 UTC, Leandro Lucarella wrote: But if there is interest, I don't discard the splitting idea in some future. It'd be great, if there was some sort of separation so that users know exactly what to use for cross-platform development and what not. Docs or some sort of a cheat sheet would be nice too. In this way users can see, if Ocean contains something interesting for the task at hand. There's less of a chance of adoption, if you have to go through the source code to see what it does. Yes, the library is fairly well documented but one of our big debts is to build the documentation. Unfortunately the project lacked document generation for basically all its life, so even when some sort of DDoc-ish format is used, it not strictly DDoc because it was never actually generated, so when we start generating the docs we'll need to do a lot of cleanup and fixing. But generating Docs is another thing that is high in our TODO list.
Re: Ocean preview finally open sourced
On Thursday, 30 June 2016 at 21:32:47 UTC, Chris wrote: On Thursday, 30 June 2016 at 21:20:16 UTC, Leandro Lucarella wrote: I'd say some parts should work out of the box (there many things that are completely OS agnostic, like containers, cache, bindings to other libraries like PCRE, etc.), and some other it would be quite some work (for example all the I/O is tied to epoll, there is one class to work with direct I/O that's super Linux specific, etc.). Hm. I'd have to see what works. I can't afford to be stuck to one OS. Maybe in some future we might want to do some sort of separation between the more algorithmic stuff and the more platform-dependent stuff, because we actually spent quite some time and effort in removing some Tango's abstractions. It is a very conscious design decision to remove as many abstraction layers as possible, and for the platform-dependent part, we definitely don't want to go back. We need to work very closely to the OS facilities, so abstractions are plain noise and source of inefficiency for us :) But if there is interest, I don't discard the splitting idea in some future.
Re: Ocean preview finally open sourced
On Thursday, 30 June 2016 at 20:59:42 UTC, Chris wrote: How much would it take to make it cross platform (Windows, Mac). Unfortunately, we still have to cater for those two outliers :) I'd say some parts should work out of the box (there many things that are completely OS agnostic, like containers, cache, bindings to other libraries like PCRE, etc.), and some other it would be quite some work (for example all the I/O is tied to epoll, there is one class to work with direct I/O that's super Linux specific, etc.).
Ocean preview finally open sourced
Hello again Dland! I'm happy to finally announce the open sourcing of our Ocean base library, just it time to keep our word and make it in June ;-) https://github.com/sociomantic-tsunami/ocean To quote the README: --- Ocean is a general purpose library, compatible with both D1 and D2, with a focus on supporting the development of high-performance, real-time applications. This focus has led to several noteworthy design choices: * Ocean is not cross-platform. The only supported platform is Linux. * Ocean assumes a single-threaded environment. Fiber-based multi-tasking is favoured, internally. * Ocean aims to minimise use of the D garbage collector. GC collect cycles can be very disruptive to real-time applications, so Ocean favours a model of allocating resources once then reusing them, wherever possible. Ocean began life as an extension of Tango, some elements of which were eventually merged into Ocean. --- Please consider this as a very early release, this is why we are "branding" it as a "preview". This is basically because, despite being working on the open sourcing full steam since DConf ended, we couldn't manage to set up all the infrastructure to be able to put all our development efforts in the public repo yet. So unfortunately the main development will still happen inside Sociomantic for this first phase (we'll only synchronize releases). When this will switch finally happens will depend on how much work it would imply to build a public infrastructure (mainly for automatic testing), and honestly, what's the community reception (we understand it might not be all that tempting being a D1 project that gets automatically converted to D2, thus not very idiomatic D2 :). Anyway, the main big step is done. You can take a look at the code, use it or steal parts of it if you find them useful (although please have a look at the licensing terms, even when all our code is Boost, there is code inherited from Tango that isn't), criticize it, and if you are really nice, fill issues and make pull requests! Also, in the near future we plan to write a blog post explaining a bit more about what Ocean is about, we'll let you know when it's ready, but we didn't want to delay the release for it :-) Thank you!
Re: Makd (build system) and d1to2fix tool (D1->D2 conversion) released as open source
On Saturday, 25 June 2016 at 01:45:17 UTC, Leandro Lucarella wrote: On Friday, 24 June 2016 at 17:20:51 UTC, Dejan Lekic wrote: On Friday, 24 June 2016 at 16:44:05 UTC, Dejan Lekic wrote: And no, some of *still love Make*! Well, I wanted to say that some of US still love Make! :) Pardon my quick typing... I count that as sign of true excitement! ;-) BTW, the project is quite mature, as we've been using it internally for years now, but there might be assumptions on the project layout (or undocumented stuff) that we overlooked. Even when we tried to keep this project general from the start with the hopes to open source it, it is sometimes hard to be able to abstract ourselves from these internal conventions. So please, if you find any issues, bad or lacking documentation, or any other issues, please report them!
Re: Makd (build system) and d1to2fix tool (D1->D2 conversion) released as open source
On Friday, 24 June 2016 at 17:20:51 UTC, Dejan Lekic wrote: On Friday, 24 June 2016 at 16:44:05 UTC, Dejan Lekic wrote: And no, some of *still love Make*! Well, I wanted to say that some of US still love Make! :) Pardon my quick typing... I count that as sign of true excitement! ;-)
Makd (build system) and d1to2fix tool (D1->D2 conversion) released as open source
Hello Dland. I just wanted to let you know we just released the first D-related projects as open source. Makd is a a GNU Make library/framework to build D projects (I know there is a lot of hate towards Make, so I'm not sure if this is good or bad news for the community :-P). https://github.com/sociomantic-tsunami/makd Also, even when it can be used to build D2, it defaults to use the `dmd1` compiler, but it can be easily change by just overriding a variable (see https://github.com/sociomantic-tsunami/makd#d2-support for details). The d1to2fix tool is a (D2) tool to do the final steps to convert D1 code to D2. It is based on libdparse and dfix and it's been a key part of our transition. Although for the rest of the community it might just a curiosity. https://github.com/sociomantic-tsunami/d1to2fix These are all dependencies to release our Ocean library, which we still aim to release late next week, hopefully fulfilling our promise to make it in June :) Thanks, and comments are welcome!
Sociomantic's short DConf2016 video
For the ones that missed it (and the ones that didn't too), here is a short video about the conference. https://vimeo.com/167235872
Re: Berlin D Meetup May 2016
On Friday, 20 May 2016 at 07:28:15 UTC, Stefan Koch wrote: Aww dammit, just missed my train. We started like one hour late because of some key issue, so next time you might want to join even if a bit later :)
Re: To all DConf speakers: please upload slides!
Steven Schveighoffer, el 12 de May a las 16:55 me escribiste: > On 5/12/16 4:13 PM, Seb wrote: > >On Wednesday, 11 May 2016 at 09:17:54 UTC, Dicebot wrote: > >>To do the editing of HD videos we need presentation slides which are > >>currently scattered over different places. It would help a lot to have > >>them all in github.com/dlang/dlang.org repo - please submit pull > >>requests asap! > > > >Just a minor complaint - would it be possible for the next dconf to have > >the slides (or a link to them) on dconf.org before the talk starts? > >Thanks for the great work! > > I think it's better to not have the slides available until the talk > starts. There may be jokes/surprises in the slides that you don't > want to give away before the talk happens :) Exactly, I would say it depends on the talk, for my talk I didn't want to provide the slides beforehand ;-) -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- 1950 we were 3 billion people on the earth, today we are 6 billion people
Re: GSoC 2016 - Precise GC
On Tuesday, 3 May 2016 at 18:15:20 UTC, Jeremy DeHaan wrote: Not sure if it is something I can get to in the course of my project though. Scanning only unions conservatively is still pretty good. And the stack, and the CPU registers, but yeah, it should be a minority.
Re: Now official: we are livestreaming DConf 2015
Dicebot, el 27 de May a las 21:38 me escribiste: On Wednesday, 27 May 2015 at 21:05:23 UTC, Leandro Lucarella wrote: Dicebot, el 27 de May a las 19:26 me escribiste: On Wednesday, 27 May 2015 at 19:23:32 UTC, Kai Nacke wrote: Hi! Any chance to change the YouTube settings? Here in Germany I get only the message: Live streaming is not available in your country due to rights issues. Regards, Kai The whole live streaming feature seems to be banned in Germany :( I am afraid there is nothing that can be done apart from using a VPN. Are you sure? Is not like it would surprise me much, but I have the feeling I have seen live streaming in DE in the past without any trickery... I was referring specifically to youtube one Me too. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- Y serán tiempos de vanos encuentros entre humano y humano; en que las fieras se comerán entre ellas y después del final; en que se abríran las tierras y los cielos... y en el medio de la nada Racing saldrá campeón. -- Ricardo Vaporeso
Re: Now official: we are livestreaming DConf 2015
Dicebot, el 27 de May a las 19:26 me escribiste: On Wednesday, 27 May 2015 at 19:23:32 UTC, Kai Nacke wrote: Hi! Any chance to change the YouTube settings? Here in Germany I get only the message: Live streaming is not available in your country due to rights issues. Regards, Kai The whole live streaming feature seems to be banned in Germany :( I am afraid there is nothing that can be done apart from using a VPN. Are you sure? Is not like it would surprise me much, but I have the feeling I have seen live streaming in DE in the past without any trickery... -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- This is what you get, when you mess with us.
Re: let (x,y) = ...
Nick Treleaven, el 19 de February a las 17:25 me escribiste: On 19/02/2015 17:00, Nick Treleaven wrote: Alternatively std.typetuple.TypeTuple can be used instead of let not for ranges and arrays though Yes, but `tuple` overloads could be added for those. Or not - the length isn't known at compile-time. Tuple already supports construction from a static array: int a, b; TypeTuple!(a, b) = Tuple!(int, int)([3, 4]); I'm hacking std.typecons so this does work: TypeTuple!(a, b) = [4, 5].tuple; Why not to integrate this let to phobos, that seems to be a lot of syntactic noise compared to : let (a, b) = [4, 5]; -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- You can try the best you can If you try the best you can The best you can is good enough
Re: I'll be presenting at NWCPP on Jan 21 at Microsoft
, el 23 de January a las 16:19 me escribiste: On Thursday, 22 January 2015 at 17:21:42 UTC, Meta wrote: I'm also interested in how the presentation went. Rust ppl too: http://discuss.rust-lang.org/t/interfacing-d-to-legacy-c-code-a-summary-of-a-competing-languages-capabilities/1406 Mmm, interesting, I wonder if the Daniel Keep that wrote that is the same Daniel Keep that was involved in D, in particular in Tango... -- Leandro Lucarella (AKA luca) http://llucax.com.ar/
Re: This Week in D, issue 2
Adam D. Ruppe, el 19 de January a las 17:05 me escribiste: http://arsdnet.net/this-week-in-d/jan-18.html http://www.reddit.com/r/programming/comments/2sy7lg/this_week_in_d_january_18_2015/ For those of you who saw the draft earlier, hit refresh to ensure you aren't seeing a cached version. RSS feed: http://arsdnet.net/this-week-in-d/twid.rss Nice, but this seems to be somehow broken. At least I use Newsblur and it has an option to show a diff for changed entries. What I see now is the first issue as the new entry, and the issue #2 as a changed issue #1 (the diff says basically almost changed, of course). Maybe there is an RSS feed ID or something you need to generate, or maybe is just the order in which they appear in the feed? Because I'm also seeing issue #1 as newer than issue #2. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- HACIA NEUQUEN: EL JUEVES SALDRA CARAVANA CON PERROS DESDE CAPITAL EN APOYO AL CACHORRO CONDENADO A MUERTE -- Crónica TV
Re: This Week in D, issue 1
Michal Minich, el 13 de January a las 14:29 me escribiste: Though RSS/Atom would be really necessary! +1, this is a must! Thanks for the effort, great wrap up! -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- PENE MUTILADO POR PENETRAR UNA ASPIRADORA -- Crónica TV
Re: This Week in D, issue 1
bearophile, el 13 de January a las 14:28 me escribiste: Adam D. Ruppe: I've started writing a weekly D newsletter. Here's the first issue, any feedback welcome! http://arsdnet.net/this-week-in-d/jan-12.html Seems good. Major Changes = They are weekly, so perhaps Changes is enough. If you can, add two or three little images to the page, like here: https://sergeytihon.wordpress.com/category/f-weekly/ If you need inspiration, this is what LLVM do: http://blog.llvm.org/2015/01/llvm-weekly-54-jan-12th-2015.html -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- La terapia no sirve: es mucho mejor pagar para hacer las perversiones que para contarlas. -- Alberto Giordano (filósofo estilista)
Re: This Week in D, issue 1
Adam D. Ruppe, el 13 de January a las 17:30 me escribiste: First draft of the rss feed: http://arsdnet.net/this-week-in-d/twid.rss That was quick! Thanks. Works with Newsblur. A favicon would be nice :-D -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- Agitamos toda la zona de la paleta al horno, vemos que una luz nos atraviesa toda la zona intestinal... -- Sidharta Kiwi
Re: We're looking for a Linuy Systems Admin!
Iain Buclaw via Digitalmars-d-announce, el 9 de January a las 11:30 me escribiste: On 9 January 2015 at 11:29, Iain Buclaw ibuc...@gdcproject.org wrote: On 9 January 2015 at 11:22, Joseph Rushton Wakeling via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On Thursday, 8 January 2015 at 16:13:24 UTC, Iain Buclaw via Digitalmars-d-announce wrote: The challenge is on. If you think it’s you we’re looking for, send us your battle plan along with a certificate of your super powers at care...@sociomantic.com. Alternatively, a motivational cover letter and resume will do, too. For now. Tempting, I was wondering if there are any Sysadmin/Devops positions within Sociomantic... :-) Yea, get your certificate of superpowers in! :-) It's January, so I'm doing my annual re-write - no harm in submitting I guess. Though I've never used Linuy before, is it like Linux? :-) Is just a test to see how much candidates are into details. We never have typos, much less make mistakes. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- Ever tried? Ever failed? - Try again! Fail better!
Re: We're looking for a Software Developer! (D language)
On Thursday, 8 January 2015 at 13:21:05 UTC, Rikki Cattermole wrote: The challenge is on. If you think it’s you we’re looking for, send us your battle plan along with a certificate of your super powers at care...@sociomantic.com. Alternatively, a motivational cover letter and resume in English will do, too. For now. Unfortunately I half wish you guys had a New Zealand office. As I am in need of a job. We already have a kiwi in our lines, Ben, they guy organizing the Berlin meetup. You can ask him how was moving from NZ to DE. ;-)
Berlin Meetup
Just re-posting in case there is people here that are not subscribed to the D general group (like me ;). http://forum.dlang.org/post/yyfeeqiuuepuzhjvk...@forum.dlang.org -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- Are you nervy, irritable, depressed, tired of life. Keep it up. -- Monty Python
Re: D2 port of Sociomantic CDGC available for early experiments
Regan Heath, el 22 de October a las 10:41 me escribiste: NO, this is completely false, and why I think you are not entirely familiar with env vars in posix. LD_PRELOAD and LD_LIBRARY_PATH affects ALL, EACH and EVERY program for example. D or not D. Every single dynamically linked program. True. And the reason these behave this way is because we *always* want them to - the same is NOT true of the proposed vars for D. No, not at all, you very rarely want to change LD_PRELOAD and LD_LIBRARY_PATH globaly. Which is my point. This is a super common mechanism. I never ever had problems with this. Did you? Did honestly you even know they existed? Yes. But this is beside the point, which I hope I have clarified now? No. My conclusion is we don't agree mainly on this: I think there are cases where you want runtime configuration to propagate or be set more or less globally. You think no one will ever want some runtime option to propagate. The rest of the argument is based on that difference. Also, I don't have much of a problem with having command-line options to configure the runtime too, although I think in linux/unix is much less natural. Runtime configuration will be most of the time some to be done either by the developer (in which case it would be nicer to have a programatic way to configure it), or on a system level, by a system administrator / devops (in which case for me environment variables are superior for me). Usually runtime options will be completely meaningless for a regular user. Also, will you document them when you use --help? Will you omit them? -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- De tan fina la condesa, por no cagarse, reza. -- Ricardo Vaporeso
Re: D2 port of Sociomantic CDGC available for early experiments
Regan Heath, el 23 de October a las 17:24 me escribiste: On Thu, 23 Oct 2014 15:27:50 +0100, Leandro Lucarella l...@llucax.com.ar wrote: Regan Heath, el 22 de October a las 10:41 me escribiste: NO, this is completely false, and why I think you are not entirely familiar with env vars in posix. LD_PRELOAD and LD_LIBRARY_PATH affects ALL, EACH and EVERY program for example. D or not D. Every single dynamically linked program. True. And the reason these behave this way is because we *always* want them to - the same is NOT true of the proposed vars for D. No, not at all, you very rarely want to change LD_PRELOAD and LD_LIBRARY_PATH globaly. Sure, but when you do change them you will want them to propagate, by default, which is why envvars are used for these. No, not at all, specially with LD_PRELOAD, I think you almost never want to propagate it. I think LD_PRELOAD is the closest example to what one would want to do with runtime options (and some of the stuff, like replacing the GC, could be done using LD_PRELOAD, actually, but you have to replace it all, you have much less fine grained control, is major surgery). Also, I don't have much of a problem with having command-line options to configure the runtime too, although I think in linux/unix is much less natural. Surely not, unix is the king of command line switches. Is not about quantity, is about separation of concerns. Historically in Linux a program only manages the switches it really knows, is not common to hijack programs arguments in Linux (even when is done by some applications, like GTK+, but is all under your control, you explicitly pass the command-line arguments to the library, so it's quite a different case). Anything that you don't control in your program, is handled by environment variables. or on a system level, by a system administrator / devops (in which case for me environment variables are superior for me). Disagree. It's not something we ever want at a system level, it's somewhere within the range of a single session - single execution. Why? On a single core I want ALL my applications by default NOT to use the concurrent GC, as it will make things slower, while on a multi-core I want to use the concurrent GC by default. You have an use case right there. If I have tons of memory, I would want to have all my programs preallocate 100MiB to speed up things. There might be more in the future, who knows... -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- Parece McGuevara's o CheDonald's
Re: D2 port of Sociomantic CDGC available for early experiments
Regan Heath, el 20 de October a las 11:39 me escribiste: On Fri, 17 Oct 2014 17:54:55 +0100, Leandro Lucarella l...@llucax.com.ar wrote: Regan Heath, el 17 de October a las 15:43 me escribiste: I think you've mistook my tone. I am not religious about this. I just think it's a bad idea for a program to alter behaviour based on a largely invisible thing (environment variable). It's far better to have a command line switch staring you in the face. But it's not the same. I don't mean to be rude, but all you (and Walter) are saying about environment is evidence of not knowing how useful they are in POSIX OSs I am aware of how they are used as I have had to deal with them in the past. :) OK, then it's even more difficult to understand your concerns or arguments. :S what's the history in those OSs and what people expect from them. D is not simply for these OSs and should be as platform agnostic as possible for core functionality. The runtime is not platform independent AT ALL. Why should you provide a platform agnostic way to configure it? I can understand it if it's free, but if you have to sacrifice something just to get a platform agnostic mechanism, for me it's not worth it at all. All these fear about how this can obscurely affect programs is totally unfunded. That just does not happen. Not at least commonly enough to ignore all the other advantages of it. Sure, but past/current env vars being used are used *privately* to a single program. NO, this is completely false, and why I think you are not entirely familiar with env vars in posix. LD_PRELOAD and LD_LIBRARY_PATH affects ALL, EACH and EVERY program for example. D or not D. Every single dynamically linked program. What you're suggesting here are env vars which will affect *all* D programs that see them. Yes, *only* D programs, something much less crazy than the standard environment variables that affect every single program (D or not D). :) If D takes over the world as we all hope it will then this will be a significantly different situation to what you are used to. No, not at all, not in the posix world. If you keep denying it usefulness and how they are different from command-line arguments, we'll keep going in circles. I am not denying they are useful. I am denying they are *better* than a command line argument *for this specific use case* OK, fair enough, but I can't buy your arguments, because they are based on false assumptions. We have a product here which uses env vars for trace flags and (without having separate var for each process) you cannot turn on trace for a single process in an execution tree, instead each child inherits the parent environment and starts to trace. So, your example is a D program, that spawns other D programs, so if you set an environment variable to affect the behaviour of the starting program, you affect also the behaviour of the child programs. Yes. How do you control which of these programs is affected by your global-affects-all-D-programs-env-var? By using setenv() from the spawned program, same as you would pass --command-line-options. This is a good example, and I can argue for environment variables for the same reason. If I want to debug this whole mess, using command-line options there is no way I can affect the whole execution tree to log useful debug information. Sure you can. You can do whatever you like with an argument, including passing a debug argument to sub-processes as required. Or, you could use custom env vars to do the same thing. But then you have to modify the program that spawns the other processes. In that case, if we assume you can modify that program, you can perfectly use setenv() in the fork()ed process before doing exec(). What you *do not* want is a global env var that indiscriminately affects every program that sees it, this gives you no control. Why not? You can control it the same as --command-line arguments if you are assuming you control the way programs are started. See, you proved my point, environment variables and command-line arguments are different and thus, useful for different situations. Sure, but the point is that a global env var that silently controls *all* D programs is a shotgun blast, and we want a needle. This is what I'm actively denying saying is a myth, you are just scaring children talking about the boogeyman. As I said before, in posix, there are already several env variable that affects each and every program, D or not D, that's dynamically linked. I have the feeling there are env variables that affects glibc too, which would affect every single C/C++/D program, even statically linked programs. I know for a fact there are plenty of libraries that are configured using env variables, so every application using those libraries will be affected by those env variables (libev/libevent or glib[1] meaning each and every gtk+ application is affected, that meaning the whole GNOME
Re: D2 port of Sociomantic CDGC available for early experiments
Regan Heath, el 17 de October a las 10:55 me escribiste: Regan Heath, el 14 de October a las 11:11 me escribiste: I still don't understand why wouldn't we use environment variables for what they've been created for, it's foolish :-) As mentioned this is not a very windows friendly/like solution. As mentioned you don't have to use a unique cross-platform solution, you can have different solutions for different OSs. No need to lower down to the worse solution. You've got it backwards. I'm looking for a *better* solution than environment variables, which are a truly horrid way to control runtime behaviour IMHO. OK, then this is now a holly war. So I'll drop it here. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- Mi infancia fue en un loft, bien al costado del río Cazabamos correcaminos y lo asábamos en el fogón Después? Después me vine grande y la ciudad me deslumbró Jugando al tejo en Lavalle me hice amigo del bongó
Re: D2 port of Sociomantic CDGC available for early experiments
Regan Heath, el 17 de October a las 15:43 me escribiste: You've got it backwards. I'm looking for a *better* solution than environment variables, which are a truly horrid way to control runtime behaviour IMHO. OK, then this is now a holly war. So I'll drop it here. I think you've mistook my tone. I am not religious about this. I just think it's a bad idea for a program to alter behaviour based on a largely invisible thing (environment variable). It's far better to have a command line switch staring you in the face. But it's not the same. I don't mean to be rude, but all you (and Walter) are saying about environment is evidence of not knowing how useful they are in POSIX OSs, what's the history in those OSs and what people expect from them. All these fear about how this can obscurely affect programs is totally unfunded. That just does not happen. Not at least commonly enough to ignore all the other advantages of it. If you keep denying it usefulness and how they are different from command-line arguments, we'll keep going in circles. Plus as Walter mentioned the environment variable is a bit like a shotgun, it could potentially affect every program executed from that context. We have a product here which uses env vars for trace flags and (without having separate var for each process) you cannot turn on trace for a single process in an execution tree, instead each child inherits the parent environment and starts to trace. So, your example is a D program, that spawns other D programs, so if you set an environment variable to affect the behaviour of the starting program, you affect also the behaviour of the child programs. This is a good example, and I can argue for environment variables for the same reason. If I want to debug this whole mess, using command-line options there is no way I can affect the whole execution tree to log useful debug information. See, you proved my point, environment variables and command-line arguments are different and thus, useful for different situations. And.. when some of those flags have different meanings in different processes it gets even worse. Why would they? Don't create problems where there are any :) Especially if one of those flags prints debugging to stdout, and the process is run as a child where input/output are parsed.. it just plain doesn't work. It's a mess. If you write to stdout (without giving the option to write to a log file) then what you did is just broken. Again, there is no point in inventing theoretical situations where you can screw anything up. You can always fabricate those. Let's stay on the domain of reality :) In all the years I've been working in Linux I never, EVER came across problems with environment variables being accidentally set. I find it very hard to believe this is a real problem. On the other hand, they saved my ass several times (LD_PRELOAD I LOVE YOU). -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- Le pedí que me enseñe a usar el mouse Pero solo quiere hablarme del Bauhaus Le pregunté si era chorra o rockera Me dijo Gertrude Stein era re-tortillera Me hizo mucho mal la cumbiera intelectual
Re: D2 port of Sociomantic CDGC available for early experiments
Dylan Knutson, el 16 de October a las 08:10 me escribiste: Wouldn't it be more generally useful to have another function like main() called init() which if present (optional) is called before/during initialisation. It would be passed the command line arguments. Then a program can chose to implement it, and can use it to configure the GC in any manner it likes. Seems like this could be generally useful in addition to solving this issue. Isn't this what module constructors are for? No, this needs to be configured WAY before any module constructor even runs... -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- Are you such a dreamer? To put the world to rights? I'll stay home forever Where two two always makes up five
Re: D2 port of Sociomantic CDGC available for early experiments
Regan Heath, el 14 de October a las 11:11 me escribiste: I still don't understand why wouldn't we use environment variables for what they've been created for, it's foolish :-) As mentioned this is not a very windows friendly/like solution. As mentioned you don't have to use a unique cross-platform solution, you can have different solutions for different OSs. No need to lower down to the worse solution. Wouldn't it be more generally useful to have another function like main() called init() which if present (optional) is called before/during initialisation. It would be passed the command line arguments. Then a program can chose to implement it, and can use it to configure the GC in any manner it likes. Seems like this could be generally useful in addition to solving this issue. It is nice, but a) a different issue, this doesn't provide initialization time configuration. Think of development vs. devops. If devops needs to debug a problem they could potentially re-run the application activating GC logging, or GC stomping. No need to recompile, no need to even have access to the source code. And b) where would this init() function live? You'll have to define it always, even if you don't want to customize anything, otherwise the compiler will have to somehow figure out if one is provided or not and if is not provided, generate a default one. Not a simple solution to implement. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- Refalar: acto de mover el peso de la masa hacia un lugar equivocado pero concreto. Todo refalo es, por cierto, una sucesión de pequeñísimos movimientos a los que un centímetro es la proporción aumentada de miles de porciones de espacio, que, al estar el piso mojado, refala. -- Ricardo Vaporeso
Re: D2 port of Sociomantic CDGC available for early experiments
Walter Bright, el 11 de October a las 16:39 me escribiste: On 10/11/2014 3:59 PM, Leandro Lucarella wrote: You can use different mechanisms in different OSs. There is no need to force a runtime to be OS-independent. If that were the case, then we should close the concurrent GC pull request now. I still don't see why it can't use a special argument to the C main() function. You can, but as someone said, sometimes you don't have control over how the program is started or there is no main. Is not the most general mechanism. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- Hey you, out there on your own Sitting naked by the phone Would you touch me?
Re: D2 port of Sociomantic CDGC available for early experiments
Walter Bright, el 11 de October a las 20:41 me escribiste: On 10/11/2014 4:23 PM, Leandro Lucarella wrote: It basically defines a bunch of environment variables and run the binary. This is a super common practice in posix systems. We are not inventing anything here. I don't know how windows or other OSs deal with defining environment variables in a script. Very basic facilities are always configured this way, for example try man 3 mallopt to see how can you change options in the malloc implementation using environment variables... I don't deny it is common practice on Linux, but defining a bunch of environment variables and then running the app, i.e. using the ev's as command line switches, seems pointless. Just use command line switches. Besides the extra flexibility, as mentioned many times, historically command-line parsing is supposed to be owned by the user's code. Libraries and runtimes are configured via environment variables. So, is more flexible and is what a Linux user would expect. Anyhow, environment variables are a common source of problems on Windows, which is why dmd, for example, uses dmd.conf instead. Fair enough, then maybe we should support them only on posix systems. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- ¿Cómo estais? ¿Cómo os senteis hoy 29 del membre de 1961 día en que conmemoreramos la nonésima setima nebulización del martir Peperino Pómoro junto al Rolo Puente en la ciudad de Jadad? -- Peperino Pómoro
Re: D2 port of Sociomantic CDGC available for early experiments
Rainer Schuetze, el 12 de October a las 10:30 me escribiste: On 12.10.2014 05:41, Walter Bright wrote: On 10/11/2014 4:23 PM, Leandro Lucarella wrote: It basically defines a bunch of environment variables and run the binary. This is a super common practice in posix systems. We are not inventing anything here. I don't know how windows or other OSs deal with defining environment variables in a script. Very basic facilities are always configured this way, for example try man 3 mallopt to see how can you change options in the malloc implementation using environment variables... I don't deny it is common practice on Linux, but defining a bunch of environment variables and then running the app, i.e. using the ev's as command line switches, seems pointless. Just use command line switches. Anyhow, environment variables are a common source of problems on Windows, which is why dmd, for example, uses dmd.conf instead. C# programs also use app.exe.config files alongside the executable to setup the application. Maybe we could do something similar. I just found this in msbuild/14.0/bin/csc.exe.config: configuration runtime gcServer enabled=true / gcConcurrent enabled=false/ /runtime /configuration Windows only please! :-) Also, completely unflexible, so to run 2 instances of the same program with different configuration you have to run one, modify the config file and then run the seconds? OUCH. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- De tan fina la condesa, por no cagarse, reza. -- Ricardo Vaporeso
Re: D2 port of Sociomantic CDGC available for early experiments
Andrei Alexandrescu, el 10 de October a las 21:25 me escribiste: On 10/10/14, 7:54 PM, Walter Bright wrote: On 10/10/2014 5:45 PM, Leandro Lucarella wrote: I still don't understand why wouldn't we use environment variables for what they've been created for, it's foolish :-) Because using environment variables to tune program X will also affect programs A-Z. Nope. Try this at your Unix command prompt: echo $CRAP CRAP=hello echo $CRAP CRAP=world echo $CRAP Your example is actually broken, because this is parsed by the shell separately, CRAP=hello is passed as an env variable to the echo command but the $CRAP expansion is evaluated before the command is called, so it will always have the value that had before every echo call (which is empty if you didn't define it before running those 3 commands). But try this for example: LANG=nonexistent perl /dev/null And see how your perl complaints. But anyway, yeah, that's the idea, there are many ways to define environment variables, and usually you never do so globally (except for things that you really want to affect the whole system, like the language). That doesn't mean you can't override it for a particular program. You can also create scripts to run programs, this is how Firefox runs for example: --- $ file /usr/bin/firefox /usr/bin/firefox: symbolic link to `../lib/firefox/firefox.sh' $ file /usr/lib/firefox/firefox.sh /usr/lib/firefox/firefox.sh: POSIX shell script, ASCII text executable $ grep -v '^#' /usr/lib/firefox/firefox.sh | head set -e MOZ_LIBDIR=/usr/lib/firefox MOZ_APP_LAUNCHER=`which $0` MOZ_APP_NAME=firefox MOZ_DEFAULT_PROFILEDIR=.mozilla/firefox MOZ_PROFILEDIR=.mozilla/firefox --- It basically defines a bunch of environment variables and run the binary. This is a super common practice in posix systems. We are not inventing anything here. I don't know how windows or other OSs deal with defining environment variables in a script. Very basic facilities are always configured this way, for example try man 3 mallopt to see how can you change options in the malloc implementation using environment variables... -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- Ladrón no es cualquiera, ladrón es quien usurpa el bien ajeno en beneficio propio, si no, no. -- Ricardo Vaporeso
Re: D2 port of Sociomantic CDGC available for early experiments
Walter Bright, el 9 de October a las 17:28 me escribiste: On 10/9/2014 7:25 AM, Dicebot wrote: At the same time I don't see what real benefit such runtime options brings to the table. This is why in my PR garbage collector is currently chosen during compilation time. Choosing at compile time is probably best. This is not (only) about picking a GC implementation, but also about GC *options/configuration*. The fact that right now to select between concurrent or not would mean using a different GC altogether is just an implementation detail. As I said, if at some point we can merge both, this wouldn't be necessary. Right now GDGC can disable the concurrent scanning, among other cool things (like enabling memory stomping, enabling logging of allocations to a file, enable logging of collections to a file, controlling the initial pools of memory when the program starts, etc.). This is very convenient to turn on/off not exactly at *runtime* but what I call *initialization time* or program startup. Because sometimes recompiling the program with different parameters is quite annoying, and as said before, for stuff that needs to be initialized *before* any actual D code is executed, sometimes is not easy to be done *inside* D code in a way that's not horrible and convoluted. I still don't understand why wouldn't we use environment variables for what they've been created for, it's foolish :-) -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- For long you live and high you fly But only if you ride the tide And balanced on the biggest wave You race towards an early grave.
Re: DConf 2014 Lightning Talks
Piotrek, el 21 de July a las 21:51 me escribiste: On Monday, 21 July 2014 at 21:39:52 UTC, Ali Çehreli wrote: Ali Çehreli's (first speaker) slides are at http://acehreli.org/AliCehreli_assumptions.pdf Ali Hi, Assume meme was great too. https://www.youtube.com/watch?v=KEP1acj29-Y#t=36s -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- I can't watch TV for four minutes without thinking I have five serious diseases. Like: Do you ever wake up tired in the mornings? Oh my god I have this, write this down. Whatever it is, I have this.
Re: D port of docopt
Bob Tolbert, el 15 de June a las 17:35 me escribiste: In order to learn D, I've worked up a port of the docopt commandline parser (original in Python http://docopt.org). https://github.com/rwtolbert/docopt.d THANK YOU. I love docopt! Since this is my first code in D, I apologize in advance for the mix if Python and C++ idioms. Since this is ported from Python, with the intention of staying compatible with future Python versions, some of that is expected, but I look for this as an chance to learn more about D. It is also a pretty useful way to write commandline interfaces. The included example that mimics the git CLI is pretty impressive. This is also my first submission as a dub project, so hopefully I got that right as well. Still needs more tests ported from Python, but it does pass the entire functional test suite for the current Python version. Regards, Bob -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- This is what you get, when you mess with us.
Re: dmd front end now switched to Boost license
Nick Sabalausky, el 14 de June a las 02:06 me escribiste: It's probably nice to have less restrictive license, but what we aim to achieve with that? Make commercial companies contribute to DMD more freely? There is no problem even with GPL. Let them build and sell their own products out of DMDFE? Highly unlikely to be a profitable anyway, and we'd better get back the patches. Wild guess: DMD in fedora, debian et al. repositories ? I doubt it. First, it's the backend that's not technically OSI, frontend was (apparently) GPL. Second, I can't imagine any Linux distro rejecting GPL - they'd have to boot the kernel and core utils, too. Boost has kinda become the favored D license anyway, Phobos etc., so it probably has a lot to do with that. Kinda weird to have the compiler and stdlib under different licenses. Not really, the standard library is included into user code (because of the templates), and that's the reason why it needs to be under a very permissive license. The compiler, on the other hand, doesn't, and one could agree is good to force people wanting to build products using the compiler FE to contribute changes back. I guess the main purpose of this is encourage proprietary tools based on the FE, but if that's the case, there are better licenses for this, like the LGPL, which let proprietary tools to link code against the DMD FE without having to release their code under a free license. With Boost, anyone can create a tool with DMD FE, improve the DMD FE in the process and distribute the modified DMD FE without offering the source code of the DMD FE to the received, which kind of sucks. In practice I guess not many people would do that, but I think it would have been a nice gesture to ask contributors how they feel about this license change, even when I think technically you are somehow giving up your rights to Digital Mars when contributing to DMDFE and thus they can do whatever they want with the code, legally speaking. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- Every 5 minutes an area of rainforest the size of a foot ball field Is eliminated
Re: dmd front end now switched to Boost license
Dmitry Olshansky, el 14 de June a las 18:18 me escribiste: 14-Jun-2014 04:46, Walter Bright пишет: On 6/13/2014 4:31 AM, Dmitry Olshansky wrote: It's probably nice to have less restrictive license, but what we aim to achieve with that? I do not want to come across as rude but from pragmatic standpoint it's not interesting. I'm not opposing it (after all I agreed to change it), I just don't see any valuable gains. 1. Boost is the least restrictive license This gains nothing in and by itself. 4 speaks of potential adv, which realistically is not something we desperately want. Maybe as a proactive move, that I could understand. 2. Minimize friction for adopting D Let's not deluge ourselves, it does nothing to do that unlike many other things. Changing license of G++ frontend to boost won't make people adopt C++ any faster. The only place of friction is backend, and opening FE for commerce doesn't help it. 3. Harmonization with usage of Boost in the runtime library In other words simplify licensing, but again compiler and runtime library do not have to have anything in common. There is no issue to begin with. 4. Allow commercial use of DMDFE (so what if someone does? It'll drive even more adoption of D!) The only strictly valid point. Making commercial compilers and tools on D front-end is the only solid result this move enables. Except is completely invalid! No free license restrict commercial use. What using boost enable is only proprietary use, i.e. changing the DMD FE and keeping the changes private, even if you distribute the binary with the compiled DMDFE. As I said before, there are licenses that allow anyone linking your code to non-free code, but you still have to provide the source code of the modified DMDFE if you distribute it. An example is LGPL. 5. Boost is well known and accepted All of licenses are well known. Again by itself it's not interesting, it won't make dmd any more easy to get into FOSS distros. So, really, I all those 5 points are invalid. All the license change allows is people using the work of others without contributing back, without any real necessity like with the standard library that contains templates or code that gets copypasted into the users code. OK, as a side effect of this, this might encourage companies not to use D but to develop tools based on DMDFE, but companies that are too lazy or to BAD not to contribute the changes back, which I'm not sure is such a good idea. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- PITUFO ENRIQUE ATEMORIZA CATAMARCA, AMPLIAREMOS -- Crónica TV
Re: dmd front end now switched to Boost license
Kapps, el 14 de June a las 18:19 me escribiste: On Saturday, 14 June 2014 at 17:17:34 UTC, Dicebot wrote: On Saturday, 14 June 2014 at 17:07:58 UTC, Leandro Lucarella wrote: OK, as a side effect of this, this might encourage companies not to use D but to develop tools based on DMDFE, but companies that are too lazy or to BAD not to contribute the changes back, which I'm not sure is such a good idea. I believe it is good thing. Standard tool chain should be as permissive as possible, with no expectations from the potential users whatsoever. If someone goes with proprietary closed solution and succeeds - it is their choice and risk to do so. And if they do so, it's beneficial to D overall. Not if they don't contribute back the changes (at least compared to using a license that allows them to build proprietary tools by linking to DMDFE but forcing them to contribute back the changes to DMDFE itself). I find hard to believe companies willing to do a full closed source proprietary tool are willing to use DMDFE with Boost license but not with LGPL. In any case, I clarify once more that probably in practice this makes a very tiny difference because usually you have to be too stupid to maintain a fork instead of contributing changes back and let upstream take care of all the updates, so I think that will hardly happens, this is more a ethical issue than a practical issue. I just wanted to point out that there might be more ethical licenses to achieve the same effect (allowing companies to build proprietary tools on top on DMDFE). -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- ¿Cómo estais? ¿Cómo os senteis hoy 29 del membre de 1961 día en que conmemoreramos la nonésima setima nebulización del martir Peperino Pómoro junto al Rolo Puente en la ciudad de Jadad? -- Peperino Pómoro
Re: dmd front end now switched to Boost license
David Nadlinger, el 14 de June a las 18:47 me escribiste: On Saturday, 14 June 2014 at 18:43:59 UTC, Walter Bright wrote: And there's another advantage I neglected to mention - it allows DMDFE code to be moved into Phobos without issues. I don't think Nick's argument is particularly compelling, but the DDMD - Phobos connection definitely makes the change very worthwhile in my opinion. Agreed, so far this looks like the most important gain from the change, and I can see some sense on using the boost license instead of something like lgpl. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- Ambition makes you look pretty ugly
Re: dmd front end now switched to Boost license
Joakim, el 14 de June a las 19:31 me escribiste: On Saturday, 14 June 2014 at 17:07:58 UTC, Leandro Lucarella wrote: No free license restrict commercial use. What using boost enable is only proprietary use, i.e. changing the DMD FE and keeping the changes private, even if you distribute the binary with the compiled DMDFE. As I said before, there are licenses that allow anyone linking your code to non-free code, but you still have to provide the source code of the modified DMDFE if you distribute it. An example is LGPL. The frontend was dual-licensed under the Artistic license, which also allows such proprietary use, so nothing has really changed. Mmm, even when is true that the Artistic license is a bit more permissive than the GPL in some aspects, I think is hardly suitable for doing serious proprietary software (that you intent to sell). From the artistic license that was distributed by DMD: You may not charge a fee for this Package itself. However, you may distribute this Package in aggregate with other (possibly commercial) programs as part of a larger (possibly commercial) software distribution provided that you do not advertise this Package as a product of your own. Is a bit hairy, I don't think any companies would want to do proprietary tools using the artistic license :) https://github.com/D-Programming-Language/dmd/blob/083271a415716cf3e35321f91826397d91c0a731/src/artistic.txt I realize you prefer the LGPL, to force others to contribute back to the frontend if they modify and distribute it, but the Boost license is much simpler and as Walter points out, proprietary use can help D's adoption. Again, I think from the practical point of view is the same. If you use boost license and tons of proprietary tools come out CHANGING the DMDFE and not contributing back, then the D community might get a boost because the have better tools but they are missing the contributions, so is hard to tell if the balance would be positive or negative. If they don't change the DMDFE (or contribute back the changes), then using boost or LGPL are the same, because it doesn't matter. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- El techo de mi cuarto lleno de galaxias
Re: Real time captioning of D presentations
Walter Bright, el 1 de June a las 13:48 me escribiste: On 6/1/2014 1:17 PM, Tobias Pankrath wrote: On Sunday, 1 June 2014 at 18:46:18 UTC, Walter Bright wrote: https://lkuper.github.io/blog/2014/05/31/your-next-conference-should-have-real-time-captioning/ I know I'd find this very useful - what do you guys think? I definitively prefer reading over watching video (and I've got the feeling I'm not alone). Wouldn't spend a single buck for this though. To publish the slides along with a text version of the talk would be an alternative. You're not alone. I can read a transcript far, far faster than watching a video. With FF, when watching native videos (webm for example), you can increase the speed of the video preserving the voice pitch. I usually use 1.5x speed and normally is very understandable :) -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- DESCARRILÓ EL GUSANO LOCO Y QUEDARON CHICOS ATRAPADOS -- Diario La Capital
Re: Scott Meyers' DConf 2014 keynote The Last Thing D Needs
Jesse Phillips, el 29 de May a las 02:38 me escribiste: On Wednesday, 28 May 2014 at 04:48:11 UTC, Jesse Phillips wrote: I did a translation of most of the code in the slides. http://dpaste.dzfl.pl/72b5cfcb72e4 I'm planning to transform it into blog post (or series). Right now it just has some scratch notes. Feel free to let me know everything I got wrong. Hoping someone can confirm or deny this thought. int x2prime = void; // (at global scope) Since x2prime is module variable, I would expect that the compiler will always initialize this to 0 since there isn't really a performance hit. Or is using void guarantee it won't get initialized (so much value in that guarantee)? global/static variables are placed in a special section in the executable. You need to put some value on it, so it is sensible to put the same value you use for initialization, but a compiler implementation could use a different value. I think void means you don't know what the value is, not is a random value or a value different from the default (which is impossible for stack values, at least if the idea behind void is to avoid the extra runtime cost ;). -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- You should've seen her face. It was the exact same look my father gave me when I told him I wanted to be a ventriloquist. -- George Constanza
Re: Scott Meyers' DConf 2014 keynote The Last Thing D Needs
Jesse Phillips, el 29 de May a las 14:28 me escribiste: On Thursday, 29 May 2014 at 11:08:03 UTC, Leandro Lucarella wrote: I think void means you don't know what the value is, not is a random value or a value different from the default (which is impossible for stack values, at least if the idea behind void is to avoid the extra runtime cost ;). The language docs state, If the Initializer is void, however, the variable is not initialized. Which I suspect is false in the case of module scope and as Steven pointed out, other times doing special don't init is costly. The thing is, you cannot not initialize a variable while writing the binary file to disk, you have to write something. Is not like with the stack that you can increase a pointer and leave the memory as is. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- We are born naked, wet and hungry Then things get worse
Re: Dconf 2014 talks - when to be available
Saurabh Das, el 28 de May a las 03:54 me escribiste: On Tuesday, 27 May 2014 at 23:48:44 UTC, currysoup wrote: On Tuesday, 27 May 2014 at 23:08:01 UTC, Leandro Lucarella wrote: Ali Çehreli, el 27 de May a las 10:40 me escribiste: On 05/27/2014 09:18 AM, Suliman wrote: apparently to stay on top of reddit for awhile. Explain plz A benefit of releasing the presentations slowly is to enable constant exposure to DConf in the coming weeks, as opposed to making all of them available and potentially watch interest die in a few days. I think they should be uploaded all ASAP and then you can do official announcements in reddit or wherever you thinks it's best to promote the language. But really, introducing artificial waiting time for people ALREADY interested and using the language in the name of marketing is really annoying! I agree 100%. Educating people currently interested is as important as marketing. I actually prefer the slow release of the videos - it gives me enough time to digest each talk and discuss it before the next one grabs mine and everyone else's attention. I think releasing one video every few days leads to much more in-depth discussion on the forum as well. Nodoby is stopping you from doing that with what I proposed. All you have to do is still do the one-every-few-days official releases, with a nice announcement. It could be called featured talk of today or whatever. Just because some people need some time digest talks it makes NO SENSE to have all the rest of the people that doesn't have that problem FORCED to wait. Seriously. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/
Re: Dconf 2014 talks - when to be available
Jacob Carlborg, el 28 de May a las 08:18 me escribiste: On 28/05/14 00:15, Leandro Lucarella wrote: I think they should be uploaded all ASAP and then you can do official announcements in reddit or wherever you thinks it's best to promote the language. But really, introducing artificial waiting time for people ALREADY interested and using the language in the name of marketing is really annoying! Yeah, I completely agree. It's like when movies were first released in the movie theaters, then, a year later on DVD. Now days people expect them to be released almost at the same time for streaming/downloading. Maybe we need an underground group that leaks D talks in bittorrent so we can get them fresh 8-) -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- No es malo que en la condición humana exista la mentira. Miente el púber si quiere ponerla. -- Ricardo Vaporeso. Madrid, 1921.
Re: Video of my LDC talk @ FOSDEM'14
Walter Bright, el 26 de May a las 11:09 me escribiste: On 5/26/2014 10:30 AM, w0rp wrote: On Monday, 26 May 2014 at 17:06:27 UTC, Walter Bright wrote: Youtube has solved all these problems - why not use it? You can view .webm directly in recent Firefox or Chrome versions on Windows, you an also view .webm in IE9 and above provided you have the right codecs installed. It's a perfectly acceptable format. It doesn't work on the browser that comes with Windows. That makes it undesirable if you wish to reach the largest audience with the least friction. Why restrict the audience if you don't have to? What is gained by using .webm that would offset the reduced audience? And there is something magical about digital media. Adding a copy to YouTube doesn't mean your webm copy will vanish. Just have both and everybody is happy. :) -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- El trabajo no sólo tara, sino que tarará y seguirá tararando. -- Ricardo Vaporeso
Re: Dconf 2014 talks - when to be available
Ali Çehreli, el 27 de May a las 10:40 me escribiste: On 05/27/2014 09:18 AM, Suliman wrote: apparently to stay on top of reddit for awhile. Explain plz A benefit of releasing the presentations slowly is to enable constant exposure to DConf in the coming weeks, as opposed to making all of them available and potentially watch interest die in a few days. I think they should be uploaded all ASAP and then you can do official announcements in reddit or wherever you thinks it's best to promote the language. But really, introducing artificial waiting time for people ALREADY interested and using the language in the name of marketing is really annoying! -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- Fantasy is as important as wisdom
Re: Scott Meyers' DConf 2014 keynote The Last Thing D Needs
Brian Schott, el 27 de May a las 20:03 me escribiste: On Tuesday, 27 May 2014 at 19:44:01 UTC, Andrew Edwards wrote: Really? What I got out of it was that D doesn't need people like him because his job is to explain the inconsistencies of the language. By designing a consistent language in the first place, people can readily understand it in all context thereby eliminating the need for people like him. Another point is that D is still small enough that we have time to fix things before they get out of control. (One of my favorite parts of this talk is when he points out that you need parenthesis in a specific kind of lambda just because the committee forgot to update the grammar specification.) This is very related to Don's message of last year's talk about ROI of breaking changes. https://www.youtube.com/watch?v=pmwKRYrfEyY#t=30m55s -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- Y serán tiempos de vanos encuentros entre humano y humano; en que las fieras se comerán entre ellas y después del final; en que se abríran las tierras y los cielos... y en el medio de la nada Racing saldrá campeón. -- Ricardo Vaporeso
Re: Gearing up for DConf 2014
Steven Schveighoffer, el 19 de May a las 15:27 me escribiste: On Mon, 19 May 2014 15:16:20 -0400, Walter Bright newshou...@digitalmars.com wrote: On 5/19/2014 11:11 AM, Andrej Mitrovic via Digitalmars-d-announce wrote: Walter Bright a.k.a. Walter Bright That just caused a stack overflow in my brain. Had to reboot it. http://www.criticalcommons.org/Members/ccManager/clips/malkovichFeedbackLoop.mp4/view I think you should produce a video at the conferee with all the attendants wearing a Walter Bright mask and simulating a QA section all saying walter bright all the time. THAT MUST HAPPEN -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- In 1995 a Japanese trawler sank, because a Russian cargo plane dropped a living cow from 30,000 feet
Re: Livestreaming DConf?
On Friday, 9 May 2014 at 19:48:20 UTC, Andrei Alexandrescu wrote: Hi folks, We at Facebook are very excited about the upcoming DConf 2014. In fact, so excited we're considering livestreaming the event for the benefit of the many of us who can't make it to Menlo Park, CA. Livestreaming entails additional costs so we're trying to assess the size of the online audience. Please follow up here and on twitter: https://twitter.com/D_Programming/status/464854296001933312 +1
Re: Interesting rant about Scala's issues
Dicebot, el 7 de April a las 12:04 me escribiste: On Monday, 7 April 2014 at 10:07:03 UTC, Regan Heath wrote: Got a DIP/spec/design to share? R I think biggest mistake of D enums is merging constants and actual enumerations into single entity which has resulted in weak typing of enumerations. Yeah, enum E { A = 1, B = 2 } is the same as: struct E { immutable A = 1, B = 2; } (leaving storage aside) Which for me it doesn't make any sense. Even thinking about the argument (you should have a big gain to introduce syntax sugar). enums should be enums, flags should be flags, and manifest constants should be... well, you got the idea. enum is to D what const is to C++ :P -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- The average person laughs 13 times a day
Re: Interesting rant about Scala's issues
Walter Bright, el 5 de April a las 21:15 me escribiste: On 4/5/2014 6:28 PM, Leandro Lucarella wrote: Walter Bright, el 5 de April a las 11:04 me escribiste: Of course, you can hide all this in a template. Well, you can emulate enums as they are now with structs too, so that doesn't change anything in the argument about why to provide syntax sugar for one and not the other. The argument for syntactic sugar is it must show a very large benefit over using a template. Having special syntax for everything makes the language unusable. What I mean is the current semantics of enum are as they are for historical reasons, not because they make (more) sense (than other possibilities). You showed a lot of examples that makes sense only because you are used to the current semantics, not because they are the only option or the option that makes the most sense. Is it better to redesign enum semantics now? Probably not, but I'm just saying :) -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- El techo de mi cuarto lleno de cometas
Re: Interesting rant about Scala's issues
bearophile, el 4 de April a las 18:39 me escribiste: Walter Bright: Thank you for the answers. Here's one: enum Index { A, B, C } T[Index.max] array; // Error: Index.max is not an int ... array[B] = t; // Error: B is not an int In the last months I've grown a moderate desire for optionally strongly typed array indexes in D (as seen in Ada, but with a What about: enum Int : int { One = 1, Two, Three } // implicitly casteable to int enum Symbolic { Dogs, Cars, Trees }// not implicitly casteable (and // maybe not even expose the // internal value) ? -- Leandro Lucarella (AKA luca) http://llucax.com.ar/
Re: Interesting rant about Scala's issues
Walter Bright, el 5 de April a las 11:04 me escribiste: On 4/5/2014 2:40 AM, Leandro Lucarella wrote: enum Symbolic { Dogs, Cars, Trees }// not implicitly casteable (and // maybe not even expose the // internal value) ? struct Symbolic { private static struct _impl { private int x; } enum Dogs = _impl(0); enum Cars = _impl(1); enum Trees = _impl(2); } Of course, you can hide all this in a template. Well, you can emulate enums as they are now with structs too, so that doesn't change anything in the argument about why to provide syntax sugar for one and not the other. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/
Re: warp: a fast C and C++ preprocessor
justme, el 31 de March a las 03:25 me escribiste: On Monday, 31 March 2014 at 00:09:34 UTC, Leandro Lucarella wrote: I think that's pretty wasteful, why won't you just use clang? What's the point of competing with another opensource project (a very good one, that took a lot of men-hour to do a good C/C++ compiler, including the preprocessor). I understand Walter did this in a couple of weeks, clang have been developed for at least 7 years now, is totally understandable that clang outperforms warp, is enough merit for warp to outperform GCC. I mean, if someone wants to have fun, go ahead, but putting community effort on that where there are so many places that are more important to put the effort on seems a bit silly. Walter taking 2 weeks to do something comparable to what the clang and gcc guys have done over many years, serves as massive advertising for D. Also, here we now have an entire project written by the man himself. That should serve as required reading for anybody who wants to learn how to code in the latest D. And it serves as a benchmark for the best C++ coders. They can try to do the same in C++ in two weeks. (I bet by the end of the two weeks the guys are ready to switch languages!) Don't take the couple of weeks too literally, this is just my impression after reading the article! Maybe it would be good if Walter said how much time did it take him to code this. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- Pack and get dressed before your father hears us, before all hell breaks loose.
Re: warp: a fast C and C++ preprocessor
ixid, el 30 de March a las 20:04 me escribiste: On Sunday, 30 March 2014 at 19:28:20 UTC, Walter Bright wrote: On 3/30/2014 10:08 AM, Kagamin wrote: On Friday, 28 March 2014 at 21:16:29 UTC, Ali Çehreli wrote: It could be useful for me just this past week in a throw-away D program that I wrote (at work! :) ) to parse some C and C++ files very crudely. As I understand, a preprocessor works on macros only, the rest is lexed minimally. Yes, it won't help much with the rest. Were those ycombinator performance figures putting warp someway behind clang valid? Perhaps we should unleash a community effort to match clang? I think that's pretty wasteful, why won't you just use clang? What's the point of competing with another opensource project (a very good one, that took a lot of men-hour to do a good C/C++ compiler, including the preprocessor). I understand Walter did this in a couple of weeks, clang have been developed for at least 7 years now, is totally understandable that clang outperforms warp, is enough merit for warp to outperform GCC. I mean, if someone wants to have fun, go ahead, but putting community effort on that where there are so many places that are more important to put the effort on seems a bit silly. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- Debemos creer en los sueños del niño. Cuando el niño sueña con tetas, se toca. -- Ricardo Vaporeso. Toulouse, 1915.
Re: Bountysource activity
Adam D. Ruppe, el 13 de March a las 18:38 me escribiste: Nick recently did a patch for this one: https://www.bountysource.com/issues/1327154-dmd-never-inlines-functions-that-could-throw+ we've had a lot of movement on this one https://www.bountysource.com/issues/1326911-dtoh-utility-convert-d-files-to-c-header-files and it pretty well works now waiting on the OK to merge: https://github.com/D-Programming-Language/tools/pull/39 Generally though, I don't think the bounties are going to change much behavior; the only issues that will be addressed are the ones that we were going to do anyway, since the dollar amount is just too small to change a business decision. Take multiple alias this for example. I've looked at the dmd source for that before and judged it would be a pretty big job - probably a week devoted to it, if not more. The bounty is $100 so that's, what, $2/hour? There's very little practical difference between that and doing it just because I felt like it; financially, I'd be better off flipping burgers. No real change to the incentive. Yeah, I see the bounties more like a reward (OK, you fixed something I wanted to be fixed, there you go) than a motivator to fix issues (I don't think anybody will say Oh! I want to work in this issue because I can make $100!). Is still better than nothing, and at least a nice gesture to the community, but definitely not bounty-driven development :D -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- Como un rinoceronte que lleva un pájaro en el lomo, yo te alimento, no te veo ni te toco.
Re: dmd 2.065.0
Szymon Gatner, el 24 de February a las 11:48 me escribiste: On Monday, 24 February 2014 at 11:45:20 UTC, Namespace wrote: On Monday, 24 February 2014 at 11:21:32 UTC, Kapps wrote: On Monday, 24 February 2014 at 11:04:14 UTC, Szymon Gatner wrote: So 2.065 is not the one that will make class methods final by default? Correct. The pull for it is https://github.com/D-Programming-Language/dmd/pull/2895 Not really. This pull introduce the virtual keyword. The next step will afaik force you to write on every method if it is virtual or final. The step afterwards will probably introduce final by default. Wait, what? That was one of C++ biggest mistakes! You are seriously wanting to do that? -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- O.K. Just a little pinprick. There'll be no more ah! But you may feel a little sick.
Re: https everywhere
Brad Anderson, el 21 de February a las 21:39 me escribiste: On Friday, 21 February 2014 at 21:37:39 UTC, Walter Bright wrote: On 2/21/2014 12:57 PM, Brad Anderson wrote: For $59.90 Walter could get a class 2 organization verification for Digital Mars and do code signing so we can get rid of that scary message when people run the installer. We use StartSSL for our code signing and website SSL and are happy with it. Would that work for all the websites? I.e. digitalmars.com, dlang.org, etc., or would it be a separate charge for each? The one cost and you could cover everything. StartSSL is novel in that all they do is verify your identity then let you generate as many certificates as you want. Most other CAs charge on a per certificate basis. I'm pretty happy with StartSSL apart from their terrible website. I use the free certificates and it works very nicely! -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- No existe nada más intenso que un reloj, ni nada más flaco que una bicicleta. No intenso como el café, ni flaco como escopeta. -- Ricardo Vaporeso
Re: https everywhere
Nick Sabalausky, el 21 de February a las 16:47 me escribiste: On 2/21/2014 4:39 PM, Brad Anderson wrote: On Friday, 21 February 2014 at 21:37:39 UTC, Walter Bright wrote: Would that work for all the websites? I.e. digitalmars.com, dlang.org, etc., or would it be a separate charge for each? The one cost and you could cover everything. StartSSL is novel in that all they do is verify your identity then let you generate as many certificates as you want. Most other CAs charge on a per certificate basis. I'm pretty happy with StartSSL apart from their terrible website. This is true (I do it on my server, hosting a couple domains ATM). However, unless they've changed it since I last looked, you can't do subdomains (other than www.*) with their free cert. No, you can use any subdomain, you can't use wildcards, but you can get as many subdomains as you want. To use several subdomains in one server, your server must support SNI[1], but any modern webserver should support it. [1] https://en.wikipedia.org/wiki/Server_Name_Indication -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- De las generaciones venideras espero, nada más, que vengan. -- Ricardo Vaporeso
Re: Bounty for -minimal compiler flag
Daniel Murphy, el 14 de February a las 22:10 me escribiste: 1100110 wrote in message news:tjgimnoqoflzrcrlw...@forum.dlang.org... I'm offering a $50 bounty on this. (Preferably Bitcoins, but I'll use bountysource if desired.) I'd say just put it on bountysource, because then there's more chance others will add to it. rules: Has to be called -minimal Dealbreaker. The description for the switch reads prevents all use of features which rely on druntime and therefore the only reasonable switch name is -nodruntime or a variation of that. -nort for short :) -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- Ideas claras, libertad y patriotismo, para mejorar la calidad de vida; claro que todo con mucha calidad, porque, joven, ideas claras, libertad o patriotismo tiene cualquiera. -- Ricardo Vaporeso
Re: dmd 2.065 beta 1 #2
Jacob Carlborg, el 23 de January a las 11:39 me escribiste: On 2014-01-23 10:15, Mathias LANG wrote: As Jacob already said, we will either need to go back to a major of 0, or improve our major number almost everytime there is a release. Ruby has just adopted the semantic versioning scheme[1] . They added a fourth digit. The first digit will be the version of the language, the remaining three digits will work as the regular semantic versioning scheme. [1] https://www.ruby-lang.org/en/news/2013/12/21/semantic-versioning-after-2-1-0/ Works for me. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- Software is like sex: it's better when it's free. -- Linus Torvalds
Re: dmd 2.065 beta 1 #2
Andrew Edwards, el 21 de January a las 20:06 me escribiste: On 1/21/14, 6:02 PM, Jordi Sayol wrote: El 21/01/14 23:29, Brad Anderson ha escrit: #.###.~b# == 2.065.b1 // beta #.###.~rc# == 2.065.rc1 // release candidate #.###.0 == 2.065.0 // initial release #.###.# == 2.065.1 // hotfix On Debian, 2.065.rc1 is bigger than 2.065.0, so if dmd_2.065.rc1-0_amd64.deb is installed and you try to upgrade to dmd_2.065.0-0_amd64.deb, system will answer something like You have installed a newer version. No problem if these deb packages are for internal use and test, but not for a public download. $ dpkg --compare-versions 2.065.0 gt 2.065.rc1 echo Bigger || echo Not bigger Apparently the same problem exists on FreeBSD. The first solution that comes to mind is to prefix the qualifiers for betas and release candidates with a tilde. As such: 2.065~b1 2.065~rc1 or: 2.065.~b1 2.065.~rc1 This solution works on both Ubuntu and FreeBSD but I'm not sure it is the right one. Suggestions are welcomed. There is a fairly popular de-facto standard for versioning: semver. Yes, it is incompatible with Debian (and I guess FreeBSD) but you can make it compatible by just changing one character (- - ~). Since apparently a version naming scheme is needed, does anyone have a good reason NOT to use a standard that's easily adaptable to several popular distributions? -- Leandro Lucarella (AKA luca) http://llucax.com.ar/
Re: dmd 2.065 beta 1 #2
Jordi Sayol, el 22 de January a las 00:16 me escribiste: If we upgrade the version scheme, we can remove the initial zero too: 2.65.b1 2.65.rc1 2.65.0 2.65.1 Why not use semver? http://semver.org/ 2.65.0-b1 2.65.0-rc1 2.65.0 2.65.1 For Debian packages simply s/-/~/ and everything works as expected. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- Your success is measured by your ability to finish things
Re: DDOX search support and new 2.064.2 Phobos docs
Sönke Ludwig, el 29 de December a las 19:07 me escribiste: DDOX [1] has just gained support for a JavaScript based live search function. I've uploaded new DMD 2.064.2 Phobos/Druntime docs [2] with this (search box in the upper-left corner). The vibe.d docs [3] are now also searchable and documentation for old releases can now also be viewed in addition to the most current release. Very nice! In FF 26 the search box is a little wider than the container though (in both phobs and vibe.d docs). -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- We are born naked, wet and hungry Then things get worse
Re: Travis-CI Skeleton Project for DMD 2.064.2 and LDC 0.12.1
Dylan Knutson, el 16 de December a las 23:03 me escribiste: On Monday, 16 December 2013 at 12:09:13 UTC, Leandro Lucarella wrote: Yeah, and this approach of compiling the compilers, even when it might be useful, seems overkill and a bit abusive for Travis. I would contact those guys, maybe they are willing to add D support, I guess it shouldn't be that hard. It's not quite that bad. The compilers are already built, I'm just pulling DMD down in the form of a .deb package, and extracting a pre-built LDC depending on the DC environment variable set. Oh, OK, since the language was set to C++ I just assumed you were compiling the compilers, then it seems pretty reasonable :) -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- A veces quisiera ser un barco, para flotar como floto siendo humano, y no hundirme como me hundo
Re: Travis-CI Skeleton Project for DMD 2.064.2 and LDC 0.12.1
Jacob Carlborg, el 16 de December a las 08:34 me escribiste: On 2013-12-16 00:31, Dylan Knutson wrote: Hello, I was hoping for Travis-CI to provide a set of D compilers for building projects written in D, but alas, they do not. So, here's a small skeleton project that I'm using for testing my D projects with DMD 2.064.2 and LDC 0.12.1. It should be straightforward to bring in the relevant parts of the .travis.yml and Makefile into another project; just copy over the .travis_scripts folder, the install and env portions of the config in .travis.yml and it should be good to go. We really need to get officially support for D in Travis. I've been thinking about this for a while but haven't done anything about it so far. Yeah, and this approach of compiling the compilers, even when it might be useful, seems overkill and a bit abusive for Travis. I would contact those guys, maybe they are willing to add D support, I guess it shouldn't be that hard. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/
Re: Build Master: Progress toward 2.065
Dicebot, el 10 de December a las 16:18 me escribiste: On Tuesday, 10 December 2013 at 15:09:13 UTC, Leandro Lucarella wrote: I don't understand. Rebasing the release branch on top of master shouldn't be an option, as it means you are taking all the changes to master and put them in the release branch. That's just using master as a release branch. The other way around would be crazy. Yes, of course, it is not a normal thing to do. As far as I understand, Andrew wants to restart release branch from scratch, based on current master state (because old base happened before he started working on release management). In that case it is a natural (and exceptional) solution. Ah, perfect, then ignore my previous message :) -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- ELLA FUE INFIEL, PERO EX POLOLO PAGÓ -- TV CHILE
Re: Build Master: Progress toward 2.065
Dicebot, el 10 de December a las 14:01 me escribiste: On Tuesday, 10 December 2013 at 12:57:10 UTC, Andrew Edwards wrote: I which case, updating with master will be counter productive. Thanks for the heads up. I will just have to rely on the devs to cherry-pick what was not originally included in the branch. cherry-picking is discouraged in that scenario as it will complicate merging 2.065 branch back into master after release. rebase sounds like best fit. I don't understand. Rebasing the release branch on top of master shouldn't be an option, as it means you are taking all the changes to master and put them in the release branch. That's just using master as a release branch. The other way around would be crazy. What problems do you see merging cherry-picked stuff back into master? IIRC git should be smart enough to recognize duplicated commits and ignore them, at least if you merge often. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- Hola soy Angie. Quería preguntarles como inserto un archivo .cab (paquete hecho en Visual Basic contiene una librería y un ocx) en Internet Explorer para después me deje trabajar en PHP con este .cab
Re: DConf 2014 Call for Submissions is now open
Andrei Alexandrescu, el 27 de November a las 09:46 me escribiste: On 11/27/13 6:37 AM, Dicebot wrote: On Wednesday, 27 November 2013 at 05:44:36 UTC, Jonathan M Davis wrote: And now I have to wrack my brain for ideas. :) I could probably answer questions about D all day, but coming up with something useful to talk about on my own never seems to be as easy as it should be... I had some until I have started to think about Credentials: What qualifies you to talk on the topic of choice?. Have honestly answered Nothing and closed the page. :) Will try my best to get there as a visitor this time though. You didn't read through the end: Although this criterion favors experienced and well-known submitters, we also very strongly encourage submissions from up-and-coming contributors who have accumulated street cred through their open source and forum contributions. Some really great talks in the previous conference were given by people than never gave a talk before ;) -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- they wrap me up in the back of the trunk packed with foam and blind drunk they won't ever take me alive cause they all drive killer cars
Re: dmd 2.064.2
Dicebot, el 6 de November a las 12:43 me escribiste: Arch Linux package has been updated. Was awaiting for some of good stuff from this release for a long time :) There are two extremely disappointing things though: 1) We still can't get versioning right. Walter has treated release candidate as a release which is why we have 2.064.2 right now as first actual release. This is not intended approach. Also I find strange that the first patchlevel version is 2 and not 1. Was that intended or just an error? -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- DETIENEN A PADRE, MADRE, TIOS Y ABUELOS: TODOS DEPRAVADOS -- Crónica TV
Re: dmd 2.064.2
Walter Bright, el 6 de November a las 12:01 me escribiste: On 11/6/2013 5:16 AM, Jordi Sayol wrote: In dmd.2.064.2.zip, src/VERSION contains 2.064. Should be 2.064.2 I deliberately didn't do that because it would have required rebuilding all the binaries just for that. And that's bad because ? -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- The Guinness Book of Records holds the record for being the most stolen book in public libraries
Re: dmd 2.064.2
Walter Bright, el 6 de November a las 11:57 me escribiste: On 11/6/2013 4:34 AM, Leandro Lucarella wrote: Also I find strange that the first patchlevel version is 2 and not 1. Was that intended or just an error? It was intended. I felt that 2.064 = 2.064.1 would have been confusing, hence 2.064 = 2.064.2 That's funny, I find it very confusing to jump from 2.064 to 2.064.2. 2.064 is implied to be 2.064.0, as version 1 is implied to be 1.0 (and as a floating point number 1 is 1.0, not 1.1). Every other project out there uses this convention. So I wonder why do you find 2.064 = 2.064.1 confusing. Looking at previous versions I just noticed you did the same with 2.063, I didn't notice then. But please, could you consider changing that naming scheme and using 2.0XX.1 as the 1st patchlevel (see the relation? :). Thanks. And I would also want to thanks for another great release, with a great changelog despite the protests! :D -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- A lo que Peperino respondióles: aquel que tenga sabañones que se los moje, aquel que padece calvicie no padece un osito, no es bueno comer lechón en día de gastritis, no mezcleis el vino con la sandía, sacad la basura después de las ocho, en caso de emergencia rompa el vidrio con el martillo, a cien metros desvio por Pavón. -- Peperino Pómoro
Re: dmd 2.064.2
Jacob Carlborg, el 6 de November a las 22:06 me escribiste: On 2013-11-06 20:57, Walter Bright wrote: It was intended. I felt that 2.064 = 2.064.1 would have been confusing, hence 2.064 = 2.064.2 That's what's happening if you start to add new digits. The first release should have possibly been 2.064.0. BTW, there was a 2.063.1, if I recall correctly. I also have the impression I saw a 2.063.1. There are certainly posts in the devel list about that version, there is none with that version in the download directory: http://downloads.dlang.org/releases/2013/ Maybe the discussion was about 2.063.1 but then Walter name it 2.063.2, or maybe it was removed from the web server? -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- Software is like sex: it's better when it's free. -- Linus Torvalds
Re: dmd 2.064.2
, el 6 de November a las 21:53 me escribiste: On Wednesday, 6 November 2013 at 20:11:13 UTC, Aleksandar Ruzicic wrote: versions must be marked with rc, as betas are marked with b flag. Something like 2.064-rc.1, 2.064-rc.2, ... 2.064 (stable/major release), 2.064.1 (patch release), ... This (-rc.xx) is how RC versions should be marked as per SEMVER standard (http://semver.org), although I know that D doesn't follow semantic versioning as defined in that standard. The D version numbers fail requirement 2 of semantic versioning: 2. A normal version number MUST take the form X.Y.Z where X, Y, and Z are non-negative integers, and MUST NOT contain leading zeroes. I know that was discussed somewhere, but I don't know/recall why there is a leading zero in the minor version number. I think because back in the stone age, it was hard to sort versions like this: 1.5 and 1.15. Lexicographically speaking 1.5 1.15. I don't think there is any reason now for leading zero, just historical reasons. It would be awesome to get DMD follow semantic versioning as much as possible. Even when is not really a library, I guess the language specification can be taken as the API. The only problem is from time to time some tiny non backwards compatible changes are made and I don't anyone would like to bump the major version because of that. But I think an exception could be made for that, and I think those changes appear less and less frequently, so it shouldn't be a big issue. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- All men are born equal But quite a few get over it
Re: dmd 2.064 release candidate 1
Walter Bright, el 4 de November a las 02:57 me escribiste: On 11/4/2013 12:35 AM, Jacob Carlborg wrote: You might want to name the release candidates properly and uniquely, just as you started to do with the betas. It'll follow the 2.063 pattern. You mean after this release it will be named 2.064.1, etc? Then don't call it a release candidate, is confusing. If is really an rc (which since you don't want to make an official announcement yet, I guess it is), please do what you did with the betas. All the same reasons to name the betas uniquely apply to release candidates. Just change beta1 with rc1 and make everybody happy. Is just one more little step! :) Please, please, please, never, ever overwrite released packages (betas and rc included) with a new one. You should consider them read-only after you create and publish them. Then be consistent with how you announce the releases (beta, rc, final) and the version numbers you are using. Thanks! -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- SEÑOR BIELSA: CON TODO RESPETO ¿USTED LO VE JUGAR A RIQUELME? -- Crónica TV
Re: Start of dmd 2.064 beta program
dennis luehring, el 31 de October a las 15:28 me escribiste: Must always use script_no1 or script_no1.d? And maybe one day I have a lot of .py files that I intend to replace with D scripts TRANSPARENTLY for their user. Will D bow at me why I use the .py extension? Is D trying to shoot his own foot? It really seems to succeed quite well. My boss is right: is just a toy pretending to be serious. sorry, but this is a very stupid comment: 1. never ever was a language successful(or not) because of its file-extension behavior - maybe in your world 2. i hope there is no other tool around try to find/analyse/whatever real Python programs by using the extension - else you need to change that anyway 3. My boss is right: is just a toy pretending to be serious - maybe, maybe not - but not because of your stupid file extension comments I think even when the wording isn't the best, what he says is true. Sometimes is hard to sell the language when things that are so trivial and fundamental (as letting file names have arbitrary names, at least for scripts) not only are broken, but are justified by the community. That's definitely not serious and discouraging. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- Hey you, don't tell me there's no hope at all Together we stand, divided we fall.
Re: Start of dmd 2.064 beta program
Craig Dillabaugh, el 31 de October a las 15:54 me escribiste: On Thursday, 31 October 2013 at 14:29:34 UTC, eles wrote: On Thursday, 31 October 2013 at 14:28:05 UTC, dennis luehring wrote: 3. My boss is right: is just a toy pretending to be serious - maybe, maybe not - but not because of your stupid file extension comments It adds. Tell to my boss about that extensions and he will be grateful for you providing him ONE MORE REASON to laugh. At me. In my experience, when it comes to software development, bosses tend to have no clue what they are talking about anyway :o) So I would just laugh back at him/her (might keep that to myself though, depending on how secure I feel my job is). This seems like a bit of bikeshedding issue. It isn't bikeshedding at all, is a functional problem, is key to understand that before you keep discussing the issue :) -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- Es erróneo pensar que el repollo es una afirmación de personalidad del volátil, es una verdura, es una verdura. -- Ricardo Vaporeso
Re: Start of dmd 2.064 beta program
dennis luehring, el 31 de October a las 18:25 me escribiste: Am 31.10.2013 17:44, schrieb Leandro Lucarella: dennis luehring, el 31 de October a las 15:28 me escribiste: Must always use script_no1 or script_no1.d? And maybe one day I have a lot of .py files that I intend to replace with D scripts TRANSPARENTLY for their user. Will D bow at me why I use the .py extension? Is D trying to shoot his own foot? It really seems to succeed quite well. My boss is right: is just a toy pretending to be serious. sorry, but this is a very stupid comment: 1. never ever was a language successful(or not) because of its file-extension behavior - maybe in your world 2. i hope there is no other tool around try to find/analyse/whatever real Python programs by using the extension - else you need to change that anyway 3. My boss is right: is just a toy pretending to be serious - maybe, maybe not - but not because of your stupid file extension comments I think even when the wording isn't the best, what he says is true. Sometimes is hard to sell the language when things that are so trivial and fundamental (as letting file names have arbitrary names, at least for scripts) not only are broken, but are justified by the community. That's definitely not serious and discouraging. sorry for my wording - but pressure sentence like My boss is right: is just a toy pretending to be serious aren't fair also Let's see if this makes both sides happy: https://github.com/D-Programming-Language/dmd/pull/2700 (I still don't see any reason to enforce any extension, ever, but this at least fixes the more pressing issue, hopefully with less resistance) -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- UNA ARTISTA HACE JABONES CON SU PROPIA GRASA LUEGO DE UNA LIPOSUCCION -- Crónica TV
Re: Article: Increasing the D Compiler Speed by Over 75%
Walter Bright, el 30 de July a las 11:13 me escribiste: On 7/30/2013 2:59 AM, Leandro Lucarella wrote: I just want to point out that being so much people getting this wrong (and even fighting to convince other people that the wrong interpretation is right) might be an indication that the message you wanted to give in that blog is not extremely clear :) It never occurred to me that anyone would have any difficulty understanding the notion of speed. After all, we deal with it every day when driving. That's a completely different context, and I don't think anyone think in terms of percentage of speed in the daily life (you just say my car is twice as fast or stuff like that, but I think people hardly say my car is 10% faster in informal contexts). For me the problem is, because in informal contexts one tend to think in multipliers of speed, not percentages (or at least I do), is where the confusion comes from, is somehow counter intuitive. I understood what you mean, but I had to think about it, my first reaction was to think you were saying the compiler took 1/4 of the original time. Then I did the math and verified what you said was correct. But I had to do the math. I'm not say is right or wrong for people to have this reflex of thinking about multipliers, I'm just saying if you care about transmitting the message as clear as you can, is better to use numbers everybody can intuitively think about. And this is in reply to Andrei too. I understand your POV, but if your main goal is communication (instead of education about side topics), I think is better to stick with numbers and language that minimizes confusion and misinterpretations. Just a humble opinion of yours truly. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- You can try the best you can If you try the best you can The best you can is good enough
Re: Article: Increasing the D Compiler Speed by Over 75%
Andrei Alexandrescu, el 2 de August a las 10:16 me escribiste: On 2013-08-02 15:44:13 +, Leandro Lucarella said: I'm not say is right or wrong for people to have this reflex of thinking about multipliers, I'm just saying if you care about transmitting the message as clear as you can, is better to use numbers everybody can intuitively think about. And this is in reply to Andrei too. I understand your POV, but if your main goal is communication (instead of education about side topics), I think is better to stick with numbers and language that minimizes confusion and misinterpretations. Just a humble opinion of yours truly. Fair enough. So what would have been a better way to convey the quantitative improvement? Reduced execution time by half? -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- Mi infancia fue en un loft, bien al costado del río Cazabamos correcaminos y lo azabamos en el fogón Después? Después me vine grande y la ciudad me deslumbró Jugando al tejo en Lavalle me hice amigo del bongó
Re: Article: Increasing the D Compiler Speed by Over 75%
Walter Bright, el 25 de July a las 18:33 me escribiste: On 7/25/2013 4:15 PM, Leandro Lucarella wrote: Walter Bright, el 25 de July a las 14:27 me escribiste: On 7/25/2013 11:49 AM, Dmitry S wrote: I am also confused by the numbers. What I see at the end of the article is 21.56 seconds, and the latest development version does it in 12.19, which is really a 43% improvement. (Which is really great too.) 21.56/12.19 is 1.77, i.e. a 75% improvement in speed. This is certainly misleading, is very easy to be confused with a time reduction of 75%, which one would expect to be 1/4 of the original time. :) I don't think it's misleading at all. Speed is distance/time. A change in speed (which is the title) is the reciprocal of a change in time. For example, a doubling of speed (100% increase) is a halving of time (50% reduction). I know is technically right, I'm just saying it can be easily confused for something else that looks much better than the actual (very good) reality, and in this case is misleading. If you say something that's technically correct but hard to understand, you are not communicating your message effectively. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- No existiría el sonido del mar si faltara en la vida oreja y caracol. -- Ricardo Vaporeso. Cosquín, 1908.
Re: Article: Increasing the D Compiler Speed by Over 75%
SomeDude, el 27 de July a las 20:27 me escribiste: On Friday, 26 July 2013 at 00:08:21 UTC, Leandro Lucarella wrote: Walter Bright, el 25 de July a las 14:27 me escribiste: On 7/25/2013 11:49 AM, Dmitry S wrote: I am also confused by the numbers. What I see at the end of the article is 21.56 seconds, and the latest development version does it in 12.19, which is really a 43% improvement. (Which is really great too.) 21.56/12.19 is 1.77, i.e. a 75% improvement in speed. This is certainly misleading, is very easy to be confused with a time reduction of 75%, which one would expect to be 1/4 of the original time. :) No, a division by 4 of the total time would be a 300% improvement in speed. The article's title looks correct to me. Again, I never said is incorrect, I said is easily to read it incorrectly, which ends up sending a wrong message. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- Wake from your sleep, the drying of your tears, Today we escape, we escape.
Re: monarch dodra granted write access to phobos, druntime, and tools
Andrei Alexandrescu, el 23 de July a las 12:23 me escribiste: On 7/23/13 8:27 AM, Leandro Lucarella wrote: You don't need push access to the blessed repository to contribute, THAT's why git exists! Only people merging stuff needs push access and is good to keep that team as small as possible (and if there is a review bottleneck then it is too small and needs to be expanded). Right now, fortunately, the lack of review doesn't seem to be a huge bottleneck, and while having committed, smart people helping could be beneficial, I think is wise not to give every contributor push access to the repo right now. I'm very surprised by your outlook. My perception is that the long queue of pending pull requests not being reviewed is the single most important bottleneck at this point in history in the path of D. By my estimates I think we'd improve the speed of D's development by at least one third if we solve this one issue. There's no other issue offering so much impact. OK, I haven't been looking at the pull request queue lately so I might have written an uninformed opinion. But anyway, you don't need to give people push access for that, people can review patches without push access. People with push access can trust certain people and blindly merge pull request those people reviewed and approved. I think having to many hands merging stuff in one project will tend to chaos. Ideally some people should have a very good global idea of what's going on with the project, even when not reviewing every commit individually, you get an idea of what's going on by just looking at the commit messages in the pull request before merging. This was my main point. I also think it may transform into a major crisis (an inflection point in pull requests rate followed by a decline) if we leave this unresolved. We must find a solution to reviewing pull requests, and fast. True, but giving more people push access is not necessarily the solution and there are other potential solutions. In the Linux world usually there is only one dictator (push access) for each repository, and he *blindly* merge stuff from lieutenants (people he trust) [1]. That seems to scale pretty well. [1] http://git-scm.com/book/en/Distributed-Git-Distributed-Workflows#Dictator-and-Lieutenants-Workflow -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- SATANAS EN COMISARIA -- Crónica TV
Re: monarch dodra granted write access to phobos, druntime, and tools
eles, el 23 de July a las 15:25 me escribiste: On Monday, 22 July 2013 at 18:08:36 UTC, Andrei Alexandrescu wrote: Please join me in congratulating monarch dodra for his admission among our github committers. We're starting with phobos, druntime, and tools access, and if all goes well, we'll extend write rights to dmd also. I would like to suggest granting dmd permissions too. From the beginning. Dmd needs a lot of work and any helping hand could... help. Any mistake that could go into dmd code could be easily reverted. This is why git exists. You don't need push access to the blessed repository to contribute, THAT's why git exists! Only people merging stuff needs push access and is good to keep that team as small as possible (and if there is a review bottleneck then it is too small and needs to be expanded). Right now, fortunately, the lack of review doesn't seem to be a huge bottleneck, and while having committed, smart people helping could be beneficial, I think is wise not to give every contributor push access to the repo right now. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- Hey you, dont help them to bury the light Don't give in without a fight.
Re: A very basic blog about D
John Colvin, el 7 de July a las 22:39 me escribiste: On Sunday, 7 July 2013 at 20:08:19 UTC, Leandro Lucarella wrote: Andrei Alexandrescu, el 7 de July a las 09:06 me escribiste: On 7/7/13 8:55 AM, Andrei Alexandrescu wrote: Here's a conformant implementation for reference: http://www.scs.stanford.edu/histar/src/pkg/echo/echo.c Hmm, that's actually not so good, it doesn't ensure that I/O was successful. Anyhow, here's a possibility: import std.stdout; void main(string[] args) { const appendNewline = args.length 1 args[1] == -n; foreach (i, arg; args[appendNewline + 1 .. $]) { if (i) write(' '); write(arg); } if (nl) writeln(); } But then I figured echo must do escape character processing, see e.g. http://www.raspberryginger.com/jbailey/minix/html/echo_8c-source.html. With that the blog entry would become quite interesting. If you want the specification, here it is :) http://pubs.opengroup.org/onlinepubs/9699919799/utilities/echo.html I prefer this one :p http://www.gnu.org/fun/jokes/echo-msg.html From the opengroup spec: If the first operand is -n, or if any of the operands contain a backslash character, the results are implementation-defined. Ah...specifications... I'm gonna stick with normal linux implementation, as described here: http://linux.die.net/man/1/echo That's not Linux, that's GNU coreutils :) -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- A buscar no lo voy a ir -- Rata (Pichi Traful, febrero de 2011)
Re: A very basic blog about D
John Colvin, el 8 de July a las 12:38 me escribiste: I prefer this one :p http://www.gnu.org/fun/jokes/echo-msg.html From the opengroup spec: If the first operand is -n, or if any of the operands contain a backslash character, the results are implementation-defined. Ah...specifications... I'm gonna stick with normal linux implementation, as described here: http://linux.die.net/man/1/echo That's not Linux, that's GNU coreutils :) Sue me :pStrangely, it's in direct contradiction with the GNU coreutils documentation, as hosted on the GNU site. You mean the joke one, or the real one? :P It seems to be the same as the real one (that I found at least), is just they are worded differently because one is in manpage format and the other one in info/html/manual format. http://www.gnu.org/software/coreutils/manual/html_node/echo-invocation.html -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- Lo último que hay que pensar es que se desalinea la memoria Hay que priorizar como causa la idiotez propia Ya lo tengo asumido -- Pablete, filósofo contemporáneo desconocido
Re: A very basic blog about D
Andrei Alexandrescu, el 7 de July a las 09:06 me escribiste: On 7/7/13 8:55 AM, Andrei Alexandrescu wrote: Here's a conformant implementation for reference: http://www.scs.stanford.edu/histar/src/pkg/echo/echo.c Hmm, that's actually not so good, it doesn't ensure that I/O was successful. Anyhow, here's a possibility: import std.stdout; void main(string[] args) { const appendNewline = args.length 1 args[1] == -n; foreach (i, arg; args[appendNewline + 1 .. $]) { if (i) write(' '); write(arg); } if (nl) writeln(); } But then I figured echo must do escape character processing, see e.g. http://www.raspberryginger.com/jbailey/minix/html/echo_8c-source.html. With that the blog entry would become quite interesting. If you want the specification, here it is :) http://pubs.opengroup.org/onlinepubs/9699919799/utilities/echo.html -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- All fathers are intimidating. They're intimidating because they are fathers. Once a man has children, for the rest of his life, his attitude is, To hell with the world, I can make my own people. I'll eat whatever I want. I'll wear whatever I want, and I'll create whoever I want. -- Jerry Seinfeld
Re: DConf 2013 Closing Keynote: Quo Vadis by Andrei Alexandrescu
Walter Bright, el 29 de June a las 01:37 me escribiste: The bottom line was the open source movement was not a very significant force in the 1980's when C++ gained traction. Open source really exploded around 2000, along with the internet. I wonder if open source perhaps needed the internet in order to be viable. Yes, I think that's the whole point, without Internet open source was extremely niche, without resources to distribute it, it was almost impossible to take off, and almost impossible to collaborate, which is the big different open source have vs traditional commercial software. Even when extremely interesting, I think the ZTC++ history before open source existed or was really viable (the free software movement started in 1983, the FSF was founded in 1985 and the open source definition was made in 1998) is irrelevant in terms to analyze if right now it would be valuable to make the reference compiler partly closed. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- EL PRIMER MONITO DEL MILENIO... -- Crónica TV
Re: DConf 2013 Closing Keynote: Quo Vadis by Andrei Alexandrescu
Joakim, el 26 de June a las 17:52 me escribiste: On Wednesday, 26 June 2013 at 11:08:17 UTC, Leandro Lucarella wrote: Joakim, el 25 de June a las 23:37 me escribiste: I don't know the views of the key contributors, but I wonder if they would have such a knee-jerk reaction against any paid/closed work. Against being paid no, against being closed YES. Please don't even think about it. It was a hell of a ride trying to make D more open to step back now. I suggest you read my original post more carefully. I have not suggested closing up the entire D toolchain, as you seem to imply. Well, I'm not. I'm sticking with what you said. I have suggested working on optimization patches in a closed-source manner and providing two versions of the D compiler: one that is faster, closed, and paid, with these optimization patches, another that is slower, open, and free, without the optimization patches. I know, and that's what my e-mail was all about. I don't know why you got another impression. I even end the e-mail saying is a very bad business model too to just offer a paid better optimizer. What we need is companies paying to people to improve the compiler and toolchain. This is slowly starting to happen, in Sociomantic we are already 2 people dedicating some time to improve D as part of our job (Don and me). Thanks for the work that you and Don have done with Sociomantic. Why do you think more companies don't do this? My point is that if Because D is a new language and isn't as polished as other programming languages. I think Sociomantic was a bit crazy to adopt it so early really (my personal opinion). But it worked well (we had to do quite a lot extra efforts but I guess the time it saves in the daily usage paid for it). there were money coming in from a paid compiler, Walter could fund even more such work. Well, I think with a paid compiler you remove one of the main reasons why early adopters can be tempted to use D, because is free. What I'm sure is Sociomantic wouldn't pick D if they had to paid at that time, because it was a statup and startup usually don't have much money at first. We need more of this, and to get this, we need companies to start using D, and to get this, we need professionalism (I agree 100% with Andrei on this one). Is a bootstrap effort, and is not like volunteers need more time to be professional, is just that you have to want to make the jump. I think this ignores the decades-long history we have with open source software by now. It is not merely wanting to make the jump, most volunteers simply do not want to do painful tasks like writing documentation or cannot put as much time into development when no money is coming in. Simply saying We have to try harder to be professional seems naive to me. Well, I guess we have very different views about the decades-long history of open source software, because I know tons of examples of applications being free, without commercial implementations or paid modules and very few with a more commercial model. Even more, the few examples I know of paid modules are quite recent, not decades-old. I think is way better to do less stuff but with higher quality, nobody is asking people for more time, is just changing the focus a bit, at least for some time. Again, this is only bootstrapping, and is always hard and painful. We need to make the jump to make companies comfortable using D, then things will start rolling by themselves. If I understand your story right, the volunteers need to put a lot of effort into bootstrapping the project to be more professional, companies will see this and jump in, then they fund development from then on out? It's possible, but is there any example you have in mind? The languages that go this completely FOSS route tend not to have as much adoption as those with closed implementations, like C++. Are you kidding me? Python, Ruby, PHP, Perl. Do I have to say more than that? Do you really think C++ took off because there are commercial implementations? Do you think being a standardized language didn't help? Do you think the fact that there was a free implementation around that it supported virtually any existing platform didn't help? Do you think the fact was it was (almost) compatible with C (which was born freeish, since back then software was freely shared between universities) didn't help? First of all, your examples are completely wrong. The projects you are mentioning are 100% free, with no closed components (except for components done by third-party). You are misstating what I said: I said commercial, not closed, You said close. Not just in the previous e-mail, but you just repeated it in this one: I have suggested working on optimization patches in a CLOSED-SOURCE manner and providing two versions of the D compiler: one that is faster, CLOSED, and paid, with these optimization patches, another that is slower, open, and free, without
Re: DConf 2013 Closing Keynote: Quo Vadis by Andrei Alexandrescu
Joakim, el 25 de June a las 23:37 me escribiste: On Tuesday, 25 June 2013 at 20:58:16 UTC, Joseph Rushton Wakeling wrote: I wonder what the response would be to injecting some money and commercialism into the D ecosystem. Given how D's whole success stems from its community, I think an open core model (even with time-lapse) would be disastrous. It'd be like kicking everyone in the teeth after all the work they put in. I don't know the views of the key contributors, but I wonder if they would have such a knee-jerk reaction against any paid/closed work. Against being paid no, against being closed YES. Please don't even think about it. It was a hell of a ride trying to make D more open to step back now. What we need is companies paying to people to improve the compiler and toolchain. This is slowly starting to happen, in Sociomantic we are already 2 people dedicating some time to improve D as part of our job (Don and me). We need more of this, and to get this, we need companies to start using D, and to get this, we need professionalism (I agree 100% with Andrei on this one). Is a bootstrap effort, and is not like volunteers need more time to be professional, is just that you have to want to make the jump. I think is way better to do less stuff but with higher quality, nobody is asking people for more time, is just changing the focus a bit, at least for some time. Again, this is only bootstrapping, and is always hard and painful. We need to make the jump to make companies comfortable using D, then things will start rolling by themselves. The current situation would seem much more of a kick in the teeth to me: spending time trying to be professional, as Andrei asks, and producing a viable, stable product used by a million developers, corporate users included, but never receiving any compensation for this great tool you've poured effort into, that your users are presumably often making money with. I understand that such a shift from being mostly OSS to having some closed components can be tricky, but that depends on the particular community. I don't think any OSS project has ever become popular without having some sort of commercial model attached to it. C++ would be nowhere without commercial compilers; linux would be unheard of without IBM and Red Hat figuring out a consulting/support model around it; and Android would not have put the linux kernel on hundreds of millions of computing devices without the hybrid model that Google employed, where they provide an open source core, paid for through increased ad revenue from Android devices, and the hardware vendors provide closed hardware drivers and UI skins on top of the OSS core. First of all, your examples are completely wrong. The projects you are mentioning are 100% free, with no closed components (except for components done by third-party). Your examples are just reinforcing what I say above. Linux is completely GPL, so it's not even only open source. Is Free Software, meaning the license if more restrictive than, for example, phobos. This means is harder to adopt by companies and you can't possibly change it in a closed way if you want to distribute a binary. Same for C++, which is not a project, is a standards, but the most successful and widespread compiler, GCC, not only is free, is the battle horse of free software, of the GNU project and created by the most extremist free software advocate ever. Android might be the only valid case (but I'm not really familiar with Android model), but the kernel, since is based on Linux, has to have the source code when released. Maybe the drivers are closed source. You are missing more closely related projects, like Python, Haskel, Ruby, Perl, and probably 90% of the newish programming languages, which are all 100% open source. And very successful I might say. The key is always breaking into the corporate ground and make those corporations contribute. There are valid examples of project using hybrid models but they are usually software as a service models, not very applicable to a compiler/language, like Wordpress, or other web applications. Other valid examples are MySQL, or QT I think used an hybrid model at least once. Lots of them died and were resurrected as 100% free projects, like StarOffice - OpenOffice - LibreOffice. And finally making the *optimizer* (or some optimizations) closed will be hardly a good business, being that there are 2 other backends out there that usually kicks DMD backend ass already, so people needing more speed will probably just switch to gdc or ldc. This talk prominently mentioned scaling to a million users and being professional: going commercial is the only way to get there. As in breaking into the commercial world? Then agreed. If you imply commercial == closing some parts of the source, then I think you are WAY OFF. -- Leandro Lucarella (AKA luca) http://llucax.com.ar