Re: DigitalMars' GSoC application has been rejected
On Tuesday, 4 March 2014 at 13:40:30 UTC, Craig Dillabaugh wrote: On Tuesday, 4 March 2014 at 11:13:32 UTC, Dejan Lekic wrote: I am quite sure I will have time for this, next year. We'll keep in touch. I had also expressed and interest in helping out with this, as had at least one other poster (Mike I think). While 2015 is still a good way off perhaps we should come up with a plan as to how we can work together so as not to duplicate effort. I always access these forums through the web-interface. Is there a way to look up the email addresses of my fellow posters? The web interface for the mailing list includes email addresses: http://lists.puremagic.com/pipermail/digitalmars-d-announce/2014-March/date.html Also, I think if you log into the webforum, it might have a link for the raw posting source including email addresses, but I don't log in so I can't say for sure.
Re: D/Objective-C 64bit
Michel Fortin wrote in message news:lfqcs6$2su5$1...@digitalmars.com... If the compiler is going to be converted to the D language (how is that progressing?), it'd probably be better to merge before that, otherwise it'll be a lot of work to port all those changes. The converter can convert git master, compile it with git master, and pass the full test suite + phobos on linux32/linux64/win32. If someone wants to give me access to an OSX box I'll get it working there too. The main problem with these patches is their use of #if in places where D's version blocks don't work. These will all need to be fixed before it is merged, as I've done for the rest of the frontend. I'm happy to help anyone set up the converter - contact me here/by email/on github. It should be as simple as 1. Build dmd master 2. git clone g...@github.com:yebblies/magicport2.git 3. Fix paths if you have a different layout than I do 4. make
Re: D/Objective-C 64bit
Jacob Carlborg wrote in message news:lfqf4t$2v1o$1...@digitalmars.com... I think Daniel has said he as a working Linux compiler. He just need to create pull requests (and get them merged) for all changes his tool requires. The changes to dmd's source are all done(!), it's now time to start putting the manually ported stuff into the main repo.
Re: D/Objective-C 64bit
On Thursday, 13 March 2014 at 12:02:24 UTC, Daniel Murphy wrote: The changes to dmd's source are all done(!), it's now time to start putting the manually ported stuff into the main repo. That's great :). -- /Jacob Carlborg
Re: D/Objective-C 64bit
On Wednesday, 12 March 2014 at 17:53:19 UTC, Andrei Alexandrescu wrote: I'll defer to domain experts on this one. Please advise. Yeah, we need some comments from Walter, Daniel, Kenji and others of the core DMD developers. Probably good to have comments from David and Iain as well, to get a LDC and GDC perspective. -- /Jacob Carlborg
Re: D/Objective-C 64bit
Am Thu, 13 Mar 2014 14:20:54 + schrieb Jacob Carlborg d...@me.com: On Wednesday, 12 March 2014 at 17:53:19 UTC, Andrei Alexandrescu wrote: I'll defer to domain experts on this one. Please advise. Yeah, we need some comments from Walter, Daniel, Kenji and others of the core DMD developers. Probably good to have comments from David and Iain as well, to get a LDC and GDC perspective. -- /Jacob Carlborg Is it possible to split objc.c into two files, one for backend interfacing functions (ObjcSymbols) and one for the generic frontend stuff?
Re: D/Objective-C 64bit
On 2014-03-13 17:16, Johannes Pfau wrote: Is it possible to split objc.c into two files, one for backend interfacing functions (ObjcSymbols) and one for the generic frontend stuff? I would guess so. I would need to take a look to see how coupled the code in objc.c is. Although, most code is for backend. -- /Jacob Carlborg
Bountysource activity
https://www.bountysource.com/issues/1325905-shared-phobos-library-doesn-t-work-on-all-linux-distributions Over $2000 in open bounties left: https://www.bountysource.com/trackers/383571-d-programming-language https://www.bountysource.com/trackers/455080-gdc https://www.bountysource.com/trackers/283332-ldc Andrei
Re: Bountysource activity
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.
Re: Bountysource activity
On Thursday, 13 March 2014 at 18:20:16 UTC, Andrei Alexandrescu wrote: https://www.bountysource.com/issues/1325905-shared-phobos-library-doesn-t-work-on-all-linux-distributions Over $2000 in open bounties left: https://www.bountysource.com/trackers/383571-d-programming-language Looks like most of these are on compiler bugs. The only Phobos one is the std.getopt one, however its situation is two abandoned patches and no clear goal as to what constitutes a change worthy of marking the issue as fixed and paying out the bounty. As for the compiler bugs... well, all of these are HARD, at least from the perspective of someone inexperienced with DMD's codebase. If they were easy, they'd have been solved already. DMD is not something you can easily dive into and start moving code around to fix big problems. Speaking from experience, it wasn't once that a 50-line patch would take me days to author and debug. And even if I were to manage through, the chances are high that the patch ends up crap because you need a lot of knowledge about how the compiler works to understand what's a good idea, and what isn't. Not even Kenji's pulls are always approved. However, the biggest problem is the open pull request count. What good is authoring a patch if no one wants to take time to review it? IMHO, we don't need more bug bounties - we need REVIEWER bounties. Some way to convince more experienced D developers to review others' contributions. I have a number of open DMD pull requests myself, and sometimes I consider bribing someone to just look at them.
GladeD - Gtk Glade Files to GtkD classes
Writing gui's by hand is not that much fun. Using glade files is also not so entertaining. GladeD creates class, out of glade files, you can inherited and implement. Glade is just a very small tool, I thought other people might find hand. Check: https://github.com/burner/gladeD
Re: Bountysource activity
On Thursday, 13 March 2014 at 18:38:45 UTC, Adam D. Ruppe wrote: 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. The difference is though that people are working on problems, hard problems even, with the compiler already for free. I for one wouldn't mind getting a $100 for fixing something I already have an interest in fixing. In other words, I don't think they do any harm.
Re: D/Objective-C 64bit
On 2014-03-13 18:13:44 +, Jacob Carlborg d...@me.com said: On 2014-03-13 17:16, Johannes Pfau wrote: Is it possible to split objc.c into two files, one for backend interfacing functions (ObjcSymbols) and one for the generic frontend stuff? I would guess so. I would need to take a look to see how coupled the code in objc.c is. Although, most code is for backend. I think that'd be a good idea too. When I wrote that code I wanted everything to be close by as it was easier to experiment, but there's no need for that now. Perhaps, instead of splitting, classes derived from frontend classes (Expression, Declaration, Type) should be moved to their corresponding files and live with other similar classes of the frontend, protected in #if DMD_OBJC blocks. -- Michel Fortin michel.for...@michelf.ca http://michelf.ca
Re: Bountysource activity
On 3/13/14, Vladimir Panteleev vladi...@thecybershadow.net wrote: However, the biggest problem is the open pull request count. What good is authoring a patch if no one wants to take time to review it? IMHO, we don't need more bug bounties - we need REVIEWER bounties. Some way to convince more experienced D developers to review others' contributions. I have a number of open DMD pull requests myself, and sometimes I consider bribing someone to just look at them. I think I know what's causing this stalling. As more bugs get fixed the bugs that are left opened are the ones which are the most complicated to fix (essentially most of the easy ones are fixed already). E.g. Kenji tends to tackle more and more complex and intricate bugs. So these complicated DMD changesets can only really be reviewed by people with intricate knowledge of the compiler. I don't think there's that many people around with that kind of knowledge. Personally, I've only ever tackled smaller bugs, most of Kenji's changesets go way over my head and I wouldn't be able to merge something like that with confidence, regardless of the autotester. You could easily substitute PHD with DMD on this page: http://matt.might.net/articles/phd-school-in-pictures/
Re: Mono-D v1.5.2 - Completion improvements, dub support fixes
On Sunday, 16 February 2014 at 12:59:31 UTC, Alexander Bothe wrote: On Sunday, 16 February 2014 at 11:49:08 UTC, Rene Zwanenburg wrote: 5) Could you pastebin me your last log file(s) please? (You can open the folder via 'Help' menu - Open Log directory) Parts of the log file is Dutch (OS language), Xamarin Studio language is set to English but most of the interface and even the log files are unaffected. I guess I'll have to take that up with the Mono Develop devs. http://pastebin.com/tBn5hGxd What I really wonder is why the last exception is occurring - In theory there can't be such exception in that case.. Which version of Mono-D do you've got installed? Anyway it might hangs in a deadlock or so while scanning all the folders - but I can't imagine that this is happening that oftenly. 6) Try to put the include paths into the project settings and try to get phobos symbol completion afterwards. I can't seem to find where to add include paths in the project settings.. You could reference them in the dub package definition temporarily. Apologies for getting back so late. I was still on a pretty old version of Dub on that machine, updating to the latest version has fixed the issue. I'm sorry for wasting your time.
Re: DigitalMars' GSoC application has been rejected
On Thursday, 13 March 2014 at 10:23:09 UTC, Joakim wrote: On Tuesday, 4 March 2014 at 13:40:30 UTC, Craig Dillabaugh wrote: On Tuesday, 4 March 2014 at 11:13:32 UTC, Dejan Lekic wrote: I am quite sure I will have time for this, next year. We'll keep in touch. I had also expressed and interest in helping out with this, as had at least one other poster (Mike I think). While 2015 is still a good way off perhaps we should come up with a plan as to how we can work together so as not to duplicate effort. I always access these forums through the web-interface. Is there a way to look up the email addresses of my fellow posters? The web interface for the mailing list includes email addresses: http://lists.puremagic.com/pipermail/digitalmars-d-announce/2014-March/date.html Also, I think if you log into the webforum, it might have a link for the raw posting source including email addresses, but I don't log in so I can't say for sure. Thanks for that link. I use the web forum exclusively, and I am usually logged in when I post, and I couldn't seem to find a email addresses for other posters.
Re: Bountysource activity
On Thursday, 13 March 2014 at 18:38:45 UTC, Adam D. Ruppe wrote: 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. I agree with Adam. While I think it's great that you're taking the bounty approach, which I suggested sometime back, this isn't enough money to incentivize people much. It might get someone like Brad, who had these issues on his todo list anyway, to reorganize his list to put the bountied items on top, but it's not going to do much more than that. I still think D needs a paid compiler to drive real change, hopefully someone will use ldc with the closed patches model I laid out in this forum earlier and push that through.
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: GladeD - Gtk Glade Files to GtkD classes
On 2014-03-13 11:03, Robert Schadek wrote: Writing gui's by hand is not that much fun. Using glade files is also not so entertaining. GladeD creates class, out of glade files, you can inherited and implement. Glade is just a very small tool, I thought other people might find hand. Check: https://github.com/burner/gladeD very neat! the test worked under windows as well. just a few tweaks were necessary cause i did not want to move yr logger into std, ... yet. i have been working on the same matter recently as well, from quite a different angle though. requires a bit more polishing and testing before i can show it. i am a little bit less motivated now that there is a viable solution to the glade awkwardness ;) /det
Re: GladeD - Gtk Glade Files to GtkD classes
On 03/13/2014 11:26 PM, captaindet wrote: very neat! the test worked under windows as well. just a few tweaks were necessary cause i did not want to move yr logger into std, ... yet. well, a boy must have dreams ;-) I didn't expect it to run under win, but hey, nice to hear i have been working on the same matter recently as well, from quite a different angle though. requires a bit more polishing and testing before i can show it. i am a little bit less motivated now that there is a viable solution to the glade awkwardness ;) or you can fix up a pull request and we can work together ...
Re: Bountysource activity
On 3/13/2014 2:38 PM, Adam D. Ruppe wrote: financially, I'd be better off flipping burgers. No real change to the incentive. I flipped burgers for a month when I was 16. Money being the same, I'd rather patch a compiler ;) But yea, if you do the math it does tend to work out less than minimum wage. Still, that's more than the $0/hr for most of the D contributions we're happy to do, so I'm not complaining. At the very least it can help support the coffee/snacks fund (ie, code fuel) for the next D contribution :)
Re: Bountysource activity
On 3/13/14, 11:38 AM, Adam D. Ruppe wrote: 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 Thanks. 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. What would make the amounts interesting? Andrei
Re: Bountysource activity
On 3/13/2014 9:05 PM, Andrei Alexandrescu wrote: What would make the amounts interesting? Just taking a stab in the dark here but...greater numbers are probably more interesting numbers? :) (Sorry I can't be more helpful/specific than that.)
Re: Bountysource activity
On 3/13/2014 4:48 PM, Andrej Mitrovic wrote: So these complicated DMD changesets can only really be reviewed by people with intricate knowledge of the compiler. I don't think there's that many people around with that kind of knowledge. I think that's a good, and important, point. And I think that's one thing that's good about the bounties: They can help encourage more people to become more knowledgeable about DMD's internals. It can help seed future DMD gurus.
Re: Bountysource activity
On 3/13/14, 6:14 PM, Nick Sabalausky wrote: On 3/13/2014 9:05 PM, Andrei Alexandrescu wrote: What would make the amounts interesting? Just taking a stab in the dark here but...greater numbers are probably more interesting numbers? :) (Sorry I can't be more helpful/specific than that.) Yah, I meant HOW MUCH would make the amounts interesting? Andrei
Re: Bountysource activity
On 3/13/14, 2:45 PM, Leandro Lucarella wrote: Is still better than nothing, and at least a nice gesture to the community, but definitely not bounty-driven development :D Probably we don't want that anyway. Where I'd hope to get is a point where bounties increase participation and dynamism, and steer work toward certain issues. Andrei
Re: Bountysource activity
On Friday, 14 March 2014 at 01:05:08 UTC, Nick Sabalausky wrote: Still, that's more than the $0/hr for most of the D contributions we're happy to do, so I'm not complaining. Aye, but it doesn't push you over the line from I'd like to do this but am too busy with other work or meh i don't care enough to actually doing it. I suspect one of those two states cover the majority of people who can but don't fix many D bugs today. So while the bounty might be a nice bonus for those who were already planning to do it anyway, it is unlikely to lead to any *new* bug fixes; the rate of bug closure before and after probably hasn't changed (I'm sure we could measure this too to confirm my gut feeling).
Re: Bountysource activity
On Friday, 14 March 2014 at 01:19:11 UTC, Andrei Alexandrescu wrote: Yah, I meant HOW MUCH would make the amounts interesting? That's hard to say, but something around 5x larger would be enough for me at least to start doing D bugs instead of taking more PHP contracts - that'd put the bounty into decision /shaping/ territory instead of just being a bonus on top of an already-made decision because then it might be a viable sum of money to cover my bills in the time it takes to do it. Though, of course, if it sits idle in the review queue for a year, that'd be a problem too. I think a good move regardless would be to write up the review criteria and link them right from the readmes so authors know what they'll be expected to do and reviewers know what to look for. Then new reviewers can come on and just follow the procedure instead of deferring to the (already overloaded) handful of people who know what to do in their heads. This isn't a bad start: https://github.com/D-Programming-Language/phobos/blob/master/CONTRIBUTING.md but could use a lot more fleshing out
Re: Bountysource activity
On 3/13/2014 9:23 PM, Adam D. Ruppe wrote: On Friday, 14 March 2014 at 01:05:08 UTC, Nick Sabalausky wrote: Still, that's more than the $0/hr for most of the D contributions we're happy to do, so I'm not complaining. Aye, but it doesn't push you over the line from I'd like to do this but am too busy with other work or meh i don't care enough to actually doing it. Depends how well one's day job is going ;) And I do think it *can* be enough to tip the scales if someone is tempted but not entirely comitted - the final straw to say Ok, you know what, I think I *will* take a shot at that after all. But I think you may be right that it isn't exactly going to get a bunch of people clamoring over Ooooh!! I'm gonna go fix that one!! As far as what *would* to that though, I really don't know (I mean, beyond obviously silly answers like Three million!). FWIW, I think there *are* dangers in going too high with the bounties (and I can't believe I just said that ;) ). Don't want to end up with contention over who gets a bounty (esp if people had already made significant contributions towards something, and then a bounty gets posted and someone else swoops in for the last little bit). Also don't want to discourage people from bothering with non-bounty issues.
Re: Bountysource activity
On 3/13/2014 9:19 PM, Andrei Alexandrescu wrote: On 3/13/14, 6:14 PM, Nick Sabalausky wrote: On 3/13/2014 9:05 PM, Andrei Alexandrescu wrote: What would make the amounts interesting? Just taking a stab in the dark here but...greater numbers are probably more interesting numbers? :) (Sorry I can't be more helpful/specific than that.) Yah, I meant HOW MUCH would make the amounts interesting? Heh, yea. The best I can say is this: My gut feeling (aka best guess, emphasis on guess) is the general ballbark for interesting would be something comparable to a person's salary/wage for whatever amount of time the work would be expected to take. Ex: something that would probably take one full workday's worth of work would be interesting at approx whatever their day job's salary works out to per workday. Admittedly, that's a pretty vague answer, too.
Re: Bountysource activity
On 3/13/2014 2:40 PM, Vladimir Panteleev wrote: The only Phobos one is the std.getopt one, however its situation is two abandoned patches and no clear goal as to what constitutes a change worthy of marking the issue as fixed and paying out the bounty. Yea, this is actually a general issue I think needs addressed. Some of the bounties can be quite unclear on what exactly is expected in order to fulfill the bounty's requirements. The waters are muddied even more when other people have already made progress towards closing the issue (ex: All the years of work Don's already put into [CTFE] copy-on-write is slow and causes huge memory usage). I find there's bounties I'm more inclined to avoid just because I don't want to step on anyone's toes. Or because if I do X and Y for a bounty, I don't want to and worry about putting the bounty's backer in an awkward position, or accidentally looking greedy, just because there was also a Z I didn't know was expected (or maybe a performance improvement wasn't *enough* of an improvement) just because the issue wasn't well-defined. But maybe I'm just being socially paranoid?
Re: Bountysource activity
On Friday, 14 March 2014 at 01:16:57 UTC, Andrei Alexandrescu wrote: Probably we don't want that anyway. Where I'd hope to get is a point where bounties increase participation and dynamism, and steer work toward certain issues. Andrei From my point of view, bounties won't be super efficient as attracting newer people, now matter how much money you put in it. From my perspective (soon-to-graduate student), there's lot of people that would like to participate to an open source project, but don't have the knowledges yet. Those who have are already involved anyway. Stepping in OSS code can feel like facing a giant behemoth, and getting familiar with a project, it's short/mid/long term goals, practices, do and don't is not easy, especially with D (a good example is the final-by-default discussion, where Dicebot pointed the schedule, while you were opposed to it, and most didn't knew about). Most of the issues are DMD issues. I wouldn't mind some extra bucks, but I know that getting familiar with DMD and bugfixing it will be far more rewarding that the $100 I could make. It would extend my knowledges and in the same time give me some code to show to a future employer. In addition, I also know that it will be a long time before I can solve any of the bug, as they require a lot of experience / knowledge of D. I think what D needs, to drive contributors in, is mentors. People that are displayed as contact points for people that wants to get involved. Then in triage, some bugs could be marked as Training bugs: ie, bugs that could be easy to fix, but should not be solved by experienced contributors before a certain period of time, unless there is a real need. This way, it would left the door open for newbie to step in, say they are interested in fixing the bug, and get a DMD guru to point them to the right way. I think someone mentionned that in the Broken thread, but D could use a documented governance model (something like a simplified Qt open governance model).
