Re: Discusssion on the Discussion of the Design for a new GC
On Thursday, 24 April 2014 at 14:22:17 UTC, Dicebot wrote: On Thursday, 24 April 2014 at 14:15:45 UTC, Orvid King wrote: On Thursday, 24 April 2014 at 10:14:07 UTC, Kagamin wrote: On Wednesday, 23 April 2014 at 18:35:26 UTC, Messenger wrote: On Wednesday, 23 April 2014 at 15:33:36 UTC, Orvid King wrote: After all of that, I intend to include a base draft of the design of the GC, along with opening the PRs and committing the starting API. So, is there something I’m missing? Am I overlooking the obvious? Is there a more practical way to produce the same results? What is the state of Rainer Schütze's precise gc? Duplication of effort and all that. Also CDGC http://www.llucax.com.ar/proj/dgc/ Ah, I hadn't realized he had actually implemented the concurrent GC he gave a talk on, I will make sure to look over the code before writing out the design. I was also planning on watching the full talk before posting the design, to make sure that it doesn't prevent any aspects of the design from working. Leandro's CDGC is used as default GC in Sociomantic applications, so it is not only implemented but also extensively production-tested :) I have pinged him to give some feedback about issues he has encountered when trying to port it to D2. I didn't find any particular issues with the porting, I just didn't get far enough with the porting. My idea was to add patches on top of the current implementation instead of rolling out a complete new implementation from the scratch, since there were a few changes to the GC in D2, the porting should be done with a lot of care. There is still also the problem with threading, see https://www.dsource.org/projects/tango/ticket/2087 for details. BTW, if someone wants to take over the porting, and also do it patch by patch I recommend consulting this repo: http://git.llucax.com.ar/w/software/dgc/cdgc.git (here is where the complete history of the changes live, not in tango). And of course, feel free to contact me for any questions advice you might need!
Re: Discusssion on the Discussion of the Design for a new GC
On Thursday, 24 April 2014 at 14:15:45 UTC, Orvid King wrote: On Thursday, 24 April 2014 at 10:14:07 UTC, Kagamin wrote: On Wednesday, 23 April 2014 at 18:35:26 UTC, Messenger wrote: On Wednesday, 23 April 2014 at 15:33:36 UTC, Orvid King wrote: After all of that, I intend to include a base draft of the design of the GC, along with opening the PRs and committing the starting API. So, is there something I’m missing? Am I overlooking the obvious? Is there a more practical way to produce the same results? What is the state of Rainer Schütze's precise gc? Duplication of effort and all that. Also CDGC http://www.llucax.com.ar/proj/dgc/ Ah, I hadn't realized he had actually implemented the concurrent GC he gave a talk on Haha, you thought I was just inventing the numbers?!? :D
Re: D Meetup in Berlin
On Thursday, 4 December 2014 at 13:10:20 UTC, Stefan wrote: On Thursday, 4 December 2014 at 12:57:59 UTC, Ben wrote: Let me know if you are interested in taking part in this or any future Berlin based events. Hi, another Sociomantic developer checking in. This sounds like a great idea, I will definitely be there. I would be totally in but unfortunately I won't be in Berlin at the time. I hope it goes well and there is another meetup soon! :-)
Re: D Meetup in Berlin
On Thursday, 4 December 2014 at 15:29:58 UTC, Martin Nowak wrote: On Thursday, 4 December 2014 at 12:57:59 UTC, Ben wrote: I am interested in organizing some meetups for D programmers in the nearby area. The first of these will be very informal and involve a social meeting at a cafe or bar to chat and gauge any interest in future events and in what direction people think these should head. I was thinking of arranging this for mid January next year but am very flexible on the dates. Sounds great, wanted to initiate that myself for quite a while, but lacked the time to do so. Lot of people use http://www.meetup.com/, maybe that would get us some more visitors. We thought of at first targeting more towards the existing community. Then see how it goes and if there is momentum and interest in doing a more open event, hosting a few talks, some of them targeted as non-D users. I think that kind of event might be more suitable to announce in http://www.meetup.com/. But we are open to other ideas too I think (I don't want to talk in Ben's behalf ;-).
Re: sudo apt-get install dmd
On Sunday, 15 March 2015 at 12:25:35 UTC, Joseph Rushton Wakeling wrote: On 14/03/15 18:31, Andrei Alexandrescu via Digitalmars-d wrote: I was looking at easy installation of dmd on ubuntu, and found this: http://d-apt.sourceforge.net/ Should we make it part of the official distribution? It would be nice to have an official apt repo. I find the way things are packaged there slightly unsatisfactory, inasmuch as it packages various different tools into the dmd-bin package (e.g. both dmd and rdmd) rather than allowing you to install/uninstall them separately. Alternatively, might be worth setting up a dlang PPA on Launchpad (I think it probably makes things easier setting up packages for multiple different Ubuntu and Debian installs). I'm not sure Ubuntu allows hosting non-FLOSS in their PPAs.
Re: unittests are really part of the build, not a special run
On Monday, 30 March 2015 at 23:26:38 UTC, Dicebot wrote: And if you suggest to build both test and normal build as part of single compiler call (building test version silently in the background) this is also very confusing addition hardly worth its gain. Making the format of unittest failures better would take us a long way. Then we can script builds so the unittest and release build are created concurrently. If it is only format that matters you an always change it via custom test runner. For example, we do have a test runner that generates JUnit-compatible XML output for Jenkins - and that was possible to do with plain `unittest` blocks even with D1 :) Main problem with changing default formatting is that it is pretty hard to choose one that is 100% right. Current one is at least simple and predictable being just an exception printout. I think having the default using the same format as compiler errors makes perfect sense. Providing extra formatters in Phobos, would be a huge gain, like a JUnit-compatible formatter, as it's a very widespread test reporting format that can be used with many tools. I agree the key is the current configurability, but providing better default and better out of the box alternatives seems like a very reasonable approach to me.
Re: DIP 1007 Preliminary Review Round 1
On Monday, 24 April 2017 at 15:58:12 UTC, rikki cattermole wrote: On the flip side, it would be great for development, feature not yet done but planned? Annotate it. Even before a release ever happens. This is not the intended usage of this DIP. The intention here is to only mark symbols that are already implemented but to avoid breakage without a clean (non-breaking) update path in a development branch. This is not to "reserve" symbols for future plan. Even when at first this is intended to be used only internally by the compiler (and runtime), I will give a more general example: In semver terms, suppose that you have a library at v1.0.0 release and you want to add a symbol to a base case that is supposed to be subclassed by user code. Normally you will do this in a v1.1.0 release, since you are adding a new feature, but since adding a new method to a base class is not really a non-breaking change, because if user code added a method with the same name in a subclass, then it will break. So this change needs to be delayed for v2.0.0, you write the code in that branch to add the method. You don't just plan it. Then you go to v1.x.x branch add the `@future` declaring that the symbol will appear in an upcoming release. So when you release v1.1.0 your user gets a nice warning and can plan how to adapt his code to the upcoming v2.0.0. At some point the user upgrades to v2.0.0 and since he had a clean non-breaking update path, what in essence will be a breaking change actually never really broke the user's code (if he incrementally upgraded from v1.0.0 to v1.1.0 and then v2.0.0). Boom! This not only allows the user to do incremental upgrades without *ever* breaking his code, it also *encourages* users to stay up to date, since doing so guarantees no breaking changing, while making a big jump from an old version to a newer one will in fact break his code. This is the spirit of this DIP. Of course it could be abused, as many other features, this is why it is suggested that at first it's only available to the compiler. But even if it makes it to the user (which I think it will be very beneficial for D), if a library author abuses this feature, just educate them, ask not to reserve arbitrary symbols as reserving symbols that are not used in the short term just annoys the users for no reason. Is like if a library author would change the name of the functions in every release just for fun. Of course he could do it, but what would be the point to it?
Re: DIP 1007 Preliminary Review Round 1
On Tuesday, 25 April 2017 at 12:33:44 UTC, Steven Schveighoffer
wrote:
Really, what you are doing is reserving the overload spot. In
cases where the overload would have selected your local
function, then you should get no warning (as the additional
symbol won't conflict). In cases where your function conflicts
with a newly-reserved base class function, then the warning
should be that you will eventually need to include the
`override` keyword.
Actually, that brings up a problem with this, what is the
mechanism to say "maybe override"? Let's say you have:
// in imported library
class Base
{
void foo() @future;
}
// in user library
class Derived : Base
{
void foo() {...} // triggers warning
}
What is the next step the user has to take to remove the
deprecation warning, but still have valid code? If you put
override on foo, it's not really overriding anything as
Base.foo doesn't really exist (right?). Basically, we need a
way to write Derived such that it works with both the @future
reserved Base.foo, and the permanent Base.foo. With
deprecation, the path is clear, you just stop using that
symbol. This is not as clear.
If adding override is allowed even when base symbol doesn't
really exist, that might work, but it needs to be explicit in
the DIP.
This is a very good point. We'll send a PR with a proposed
solution to address this issue soon.
Thanks!
Re: DIP 1006 - Preliminary Review Round 1
On Tuesday, 6 March 2018 at 10:17:42 UTC, Walter Bright wrote: On 3/6/2018 1:58 AM, Jonathan M Davis wrote: [...] The entire point of making assert a core language feature was so that the compiler could take advantage of it to generate better code. It's been like that for D since day 1. It has always been documented to do that. It has been discussed many times in this n.g. over the years with lng threads. I designed it that way so that D could potentially produce better code than other languages in ways they could not match. There is no other purpose to making it a core language feature. It's fine if you want an assert-like feature to have other semantics - just define one called 'check', give it the semantics you want, and put it in the library. As I mentioned to Timon, support for that sort of thing is why D has special support for __LINE__ and __FILE__. As a side node, we have a `verify()` exactly for this: https://github.com/sociomantic-tsunami/ocean/blob/v3.x.x/src/ocean/core/Verify.d (and because in some circumstances we need to be able to catch programming errors in servers that are low risk to catch and just ignore the current request and continue with our lives, with asserts we can't do that because they throw an Error).
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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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 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
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
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
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 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
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: 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: 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: 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. ;-)
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: 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: 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: 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: 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: 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
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!
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! ;-)
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: 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 :)
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: 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.
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: 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.).
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 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: 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
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: 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? :)
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.
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!
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: 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 :-)
