Re: indie game contests
Got very close to a year or so ago. Probably something I would be much more capable of doing now. The only downside is that I enjoy doing asset creation more. On Sat, May 23, 2015 at 7:34 AM, Vlad Levenfeld via Digitalmars-d wrote: > On Friday, 22 May 2015 at 17:00:06 UTC, Namespace wrote: >> >> On Friday, 22 May 2015 at 16:24:18 UTC, Vlad Levenfeld wrote: >>> >>> I know there's a strong gamedev presence here, so I'm wondering if >>> anyone's submitted any games written in D to any of these contests? What was >>> your experience like? >>> >>> I'd like to enter one, and wonder if anyone would be interested in a >>> collaboration. >>> >>> Outside of programming, I used to do low-poly 3d art (just as a hobby in >>> my secondary school days), so I can potentially contribute visuals, and I'm >>> pretty comfortable with openGL. >> >> >> From time to time I'm working on two smaller games, "Angry Snowball" >> (https://github.com/Dgame/AngrySnowball) and "Quinn Quadrat". I would like >> to present them, once they are ready, at "one game a month", but in the last >> few week I was busy with my studies. >> I would like to collaborate with you, but you should know that my pixel >> art is not that good. ;) > > > Let's do it! > > Maybe we can get some diablo style prerendered sprites going :) > > I'm at vlevenfeld (at) gmail and github.com/evenex
Re: Boy, std.bitmanip.bigEndianToNative is annoying to use
On 23/05/2015 7:48 a.m., Jonathan M Davis wrote:
On Friday, 22 May 2015 at 19:44:59 UTC, H. S. Teoh wrote:
On Fri, May 22, 2015 at 12:39:12PM -0700, H. S. Teoh via Digitalmars-d
wrote:
[...]
face.palm();
head.hang!inShame();
self.crawlBackTo(hole);
[...]
Truth be told, though, the error message was very unhelpful about it. It
just says no templates were matched, no indication about the fact that
the problem was caused by mismatched type lengths.
Well, I'm not sure how we could fix that. That's a general problem with
template constraints. You know that they aren't passing, but you don't
know _why_ they aren't passing. Though maybe in this case, the docs
could be improved to make it clearer that if you're getting compilation
errors, there's a decent chance that you got the type sizes wrong.
- Jonathan M Davis
template X(T, string v) if (is(T == class) && v.length == 2) {
} else {
pragma(msg, "X must have two template arguments, where the first is a
class symbol and the second is a string with a length of two characters.");
}
Or
template X() if (false) {
pragma(msg, "X must have two template arguments, where the first is a
class symbol and the second is a string with a length of two characters.");
}
Humm, the first would be abused a lot. The second would be highly
limiting. The first, but all overloads must be in the style of if, else
template, else. But how to limit it to one name..
Anyway just some random thoughts.
Re: std.allocator: FreeList uses simple statistics to control number of items
On 5/22/15 9:26 AM, Martin Nowak wrote: A one-pole low pass filter is a very efficient moving average. https://github.com/D-Programming-Language/druntime/blob/6e55b7aaff7566d374c2f253f831d3489e7fd1a5/src/gc/gc.d#L1732 Feed it with 1 on hit and 0 on miss to get Phit on average. On 5/22/15 9:19 AM, Martin Nowak wrote: You can look at jemalloc which has a GC algorithm for this problem. https://m.facebook.com/notes/facebook-engineering/scalable-memory-allocation-using-jemalloc/480222803919 These are both solid. Thanks!! -- Andrei
Re: indie game contests
On Friday, 22 May 2015 at 17:00:06 UTC, Namespace wrote: On Friday, 22 May 2015 at 16:24:18 UTC, Vlad Levenfeld wrote: I know there's a strong gamedev presence here, so I'm wondering if anyone's submitted any games written in D to any of these contests? What was your experience like? I'd like to enter one, and wonder if anyone would be interested in a collaboration. Outside of programming, I used to do low-poly 3d art (just as a hobby in my secondary school days), so I can potentially contribute visuals, and I'm pretty comfortable with openGL. From time to time I'm working on two smaller games, "Angry Snowball" (https://github.com/Dgame/AngrySnowball) and "Quinn Quadrat". I would like to present them, once they are ready, at "one game a month", but in the last few week I was busy with my studies. I would like to collaborate with you, but you should know that my pixel art is not that good. ;) Let's do it! Maybe we can get some diablo style prerendered sprites going :) I'm at vlevenfeld (at) gmail and github.com/evenex
Re: Boy, std.bitmanip.bigEndianToNative is annoying to use
On Friday, 22 May 2015 at 20:21:59 UTC, Kagamin wrote: Hmm, now that I look at it, the declaration of bigEndianToNative is weird: http://dpaste.dzfl.pl/6fad7c9ef22d What's weird about it? - Jonathan M Davis
Re: Boy, std.bitmanip.bigEndianToNative is annoying to use
Hmm, now that I look at it, the declaration of bigEndianToNative is weird: http://dpaste.dzfl.pl/6fad7c9ef22d
Re: Boy, std.bitmanip.bigEndianToNative is annoying to use
On Friday, 22 May 2015 at 19:48:21 UTC, Jonathan M Davis wrote: Well, I'm not sure how we could fix that. Remove filter n == T.sizeof ?
Re: Boy, std.bitmanip.bigEndianToNative is annoying to use
On 5/22/15 12:48 PM, Jonathan M Davis wrote: On Friday, 22 May 2015 at 19:44:59 UTC, H. S. Teoh wrote: On Fri, May 22, 2015 at 12:39:12PM -0700, H. S. Teoh via Digitalmars-d wrote: [...] face.palm(); head.hang!inShame(); self.crawlBackTo(hole); [...] Truth be told, though, the error message was very unhelpful about it. It just says no templates were matched, no indication about the fact that the problem was caused by mismatched type lengths. Well, I'm not sure how we could fix that. That's a general problem with template constraints. You know that they aren't passing, but you don't know _why_ they aren't passing. Though maybe in this case, the docs could be improved to make it clearer that if you're getting compilation errors, there's a decent chance that you got the type sizes wrong. Yah, improving the documentation has maximum impact here. Navigating to github.com/pulls?user=D-Programming-Language... F5... F5... F5... F5... -- Andrei
Re: 0 is not a power of 2
On Friday, 22 May 2015 at 05:24:15 UTC, Jay Norwood wrote: first result uses if (((x-1)&(x|0x8000))==0) 00F81005 mov eax,edx 00F81007 lea ecx,[edx-1] 00F8100A or eax,8000h 00F8100F testecx,eax Above is what a Microsoft C++ compiler does with the first expression. It gets inserted in-line in the test.
Re: Boy, std.bitmanip.bigEndianToNative is annoying to use
On Friday, 22 May 2015 at 19:44:59 UTC, H. S. Teoh wrote: On Fri, May 22, 2015 at 12:39:12PM -0700, H. S. Teoh via Digitalmars-d wrote: [...] face.palm(); head.hang!inShame(); self.crawlBackTo(hole); [...] Truth be told, though, the error message was very unhelpful about it. It just says no templates were matched, no indication about the fact that the problem was caused by mismatched type lengths. Well, I'm not sure how we could fix that. That's a general problem with template constraints. You know that they aren't passing, but you don't know _why_ they aren't passing. Though maybe in this case, the docs could be improved to make it clearer that if you're getting compilation errors, there's a decent chance that you got the type sizes wrong. - Jonathan M Davis
Re: Boy, std.bitmanip.bigEndianToNative is annoying to use
On Fri, May 22, 2015 at 12:39:12PM -0700, H. S. Teoh via Digitalmars-d wrote: [...] > face.palm(); > head.hang!inShame(); > self.crawlBackTo(hole); [...] Truth be told, though, the error message was very unhelpful about it. It just says no templates were matched, no indication about the fact that the problem was caused by mismatched type lengths. T -- Verbing weirds language. -- Calvin (& Hobbes)
Re: Boy, std.bitmanip.bigEndianToNative is annoying to use
On Fri, May 22, 2015 at 07:21:40PM +, Jonathan M Davis via Digitalmars-d
wrote:
[...]
> Isn't the problem that you're trying to convert to a ushort, and a
> ushort is _2_ bytes, not 4? If you sliced it correctly, it would
> compile. For instance, this code compiles just fine for me with dmd
> master:
>
> void main()
> {
> import std.bitmanip;
> auto buf = new ubyte[](32);
> auto result = bigEndianToNative!ushort(buf[0 .. 2]);
> }
>
> But if I change it to buf[0 .. 4], then it fails to compile. So, the
> fact that bigEndianToNative is taking a static array is actually
> catching a bug for you.
[...]
face.palm();
head.hang!inShame();
self.crawlBackTo(hole);
T
--
Perhaps the most widespread illusion is that if we were in power we would
behave very differently from those who now hold it---when, in truth, in order
to get power we would have to become very much like them. -- Unknown
Re: Boy, std.bitmanip.bigEndianToNative is annoying to use
On 5/22/15 12:21 PM, Jonathan M Davis wrote: But if I change it to buf[0 .. 4], then it fails to compile. So, the fact that bigEndianToNative is taking a static array is actually catching a bug for you. Profession of undying love for D language in 3, 2, 1, ... :o) -- Andrei
Re: Boy, std.bitmanip.bigEndianToNative is annoying to use
On Friday, 22 May 2015 at 19:10:41 UTC, H. S. Teoh wrote:
In the spirit of forum bickering, ;-) I stumbled upon this D
wart today:
I'm reading some data from a file into a ubyte[] buffer, and I
want to
use bigEndianToNative to convert ushort values in the file data
into
native byte order (whatever the native order might be).
Sounds simple, right? Unfortunately, bigEndianToNative asks for
ubyte[n]
as input. Meaning, this doesn't work:
ubyte[] buf = ... /* allocate buffer here */;
file.rawRead(buf); // Read the data
ushort myValue = bigEndianToNative!ushort(buf[4 .. 8]); // NG
The last line doesn't compile, 'cos you can't convert a slice
of ubyte[]
into ubyte[4].
I can think of no easy way to declare a temporary ubyte[4] to
make
bigEndianToNative happy, other than this silly verbosity:
ubyte[4] tmp;
tmp[] = buf[4 .. 8];
ushort myValue = bigEndianToNative!ushort(tmp);
and I have to do this for every single numerical field in the
data
buffer that I need to convert. :-( Why should I copy data
around that's
already sitting in a ubyte[] buffer intended precisely for the
purpose
of doing such conversions in the first place??
The docs for bigEndianToNative claims that this is to help
"prevent
accidentally using a swapped value as a regular one". But I
say, "Why,
oh why???" :-(
This is a very anti-user kind of API. How did we think such a
straitjacketed API was a good idea in the first place?!
Isn't the problem that you're trying to convert to a ushort, and
a ushort is _2_ bytes, not 4? If you sliced it correctly, it
would compile. For instance, this code compiles just fine for me
with dmd master:
void main()
{
import std.bitmanip;
auto buf = new ubyte[](32);
auto result = bigEndianToNative!ushort(buf[0 .. 2]);
}
But if I change it to buf[0 .. 4], then it fails to compile. So,
the fact that bigEndianToNative is taking a static array is
actually catching a bug for you.
- Jonathan M Davis
Boy, std.bitmanip.bigEndianToNative is annoying to use
In the spirit of forum bickering, ;-) I stumbled upon this D wart today: I'm reading some data from a file into a ubyte[] buffer, and I want to use bigEndianToNative to convert ushort values in the file data into native byte order (whatever the native order might be). Sounds simple, right? Unfortunately, bigEndianToNative asks for ubyte[n] as input. Meaning, this doesn't work: ubyte[] buf = ... /* allocate buffer here */; file.rawRead(buf); // Read the data ushort myValue = bigEndianToNative!ushort(buf[4 .. 8]); // NG The last line doesn't compile, 'cos you can't convert a slice of ubyte[] into ubyte[4]. I can think of no easy way to declare a temporary ubyte[4] to make bigEndianToNative happy, other than this silly verbosity: ubyte[4] tmp; tmp[] = buf[4 .. 8]; ushort myValue = bigEndianToNative!ushort(tmp); and I have to do this for every single numerical field in the data buffer that I need to convert. :-( Why should I copy data around that's already sitting in a ubyte[] buffer intended precisely for the purpose of doing such conversions in the first place?? The docs for bigEndianToNative claims that this is to help "prevent accidentally using a swapped value as a regular one". But I say, "Why, oh why???" :-( This is a very anti-user kind of API. How did we think such a straitjacketed API was a good idea in the first place?! T -- Curiosity kills the cat. Moral: don't be the cat.
PTHREAD_MUTEX_INITIALIZER seems defined wrongly on OSX
Any OSX experts could weigh on this? https://issues.dlang.org/show_bug.cgi?id=14617. Thanks! -- Andrei
Re: D installer installs outdated D
On Friday, 22 May 2015 at 17:49:49 UTC, Chris wrote: So I found myself in this page: http://wiki.dlang.org/Installing_DMD Which says: Easiest and fastest way to get your DMD running on MS Windows is to use DInstaller So if I download and run DInstaller, I get D v2.062 This caused me a large amount of frustration until I realized I was working with an outdated version :( Best to use the installer download on the main site: http://dlang.org/download.html I've changed the wiki article to link to that page instead.
Re: D installer installs outdated D
On 5/22/15 10:53 AM, Chris wrote: Hi other Chris. Just to make sure, people can tell us apart :-) Uh, oh; an identity Chrisis!
Re: D installer installs outdated D
On Friday, 22 May 2015 at 17:57:07 UTC, David Gileadi wrote: On 5/22/15 10:53 AM, Chris wrote: Hi other Chris. Just to make sure, people can tell us apart :-) Uh, oh; an identity Chrisis! That's a good one! I doff my hat.
Re: D installer installs outdated D
On Friday, 22 May 2015 at 17:49:49 UTC, Chris wrote: So I found myself in this page: http://wiki.dlang.org/Installing_DMD Which says: Easiest and fastest way to get your DMD running on MS Windows is to use DInstaller So if I download and run DInstaller, I get D v2.062 This caused me a large amount of frustration until I realized I was working with an outdated version :( Hi other Chris. Just to make sure, people can tell us apart :-)
D installer installs outdated D
So I found myself in this page: http://wiki.dlang.org/Installing_DMD Which says: Easiest and fastest way to get your DMD running on MS Windows is to use DInstaller So if I download and run DInstaller, I get D v2.062 This caused me a large amount of frustration until I realized I was working with an outdated version :(
Re: Uphill
On Friday, 22 May 2015 at 17:05:10 UTC, H. S. Teoh wrote: On Fri, May 22, 2015 at 04:00:28PM +, Jonathan M Davis via Digitalmars-d wrote: On Friday, 22 May 2015 at 14:11:49 UTC, H. S. Teoh wrote: >+1, finally, something other than the usual bickering on the >forum. >;-) LOL. Don't worry. I'm sure that someone will come along and start griping about something soon. :( Joking aside, we do seem to frequently have the problem that what we have is good enough that folks expect it to be perfect and thus start complaining about how we don't do something well enough when we actually do it better than most anyone else. D certainly isn't perfect - and we _do_ have areas to improve upon - but we what we do have is pretty darn awesome. [...] Agreed, D does have its warts and dark corners, but overall it's extremely awesome. I just can't bring myself to starting new projects in any other language these days True, true. If I have the choice, it's D. If it's another language, I very soon start to miss D's features. (unless I get paid to do it, of course). D has totally wrecked my life, and it's all yall's fault!! j/k T
Re: Uphill
On Friday, 22 May 2015 at 17:05:10 UTC, H. S. Teoh wrote: Agreed, D does have its warts and dark corners, but overall it's extremely awesome. I just can't bring myself to starting new projects in any other language these days (unless I get paid to do it, of course). D has totally wrecked my life, and it's all yall's fault!! j/k LOL. The problem I have is that I'm not learning any new languages anymore. Not only do I never have enough time to do all that I want to get done with D itself, but if I'm working on a project that I care about at all, I want to do it in D. But in my experience, to really learn a new language, you need to either be using it all the time at work, or you need to be using it as you go-to language for all of your side projects. If you don't, you don't really end up using it enough to really learn it. And since I really want to be doing my side projects in D (and I work in C++), I'm really not experimenting with other languages much, and I'm definitely not learning them well. I haven't even learned C++11/14 properly, because I can't use it at work yet, and almost all the programming I do in my free time is in D. But everything other than D is just so frustrating anyway. ;) - Jonathan M Davis
Re: Uphill
On Fri, May 22, 2015 at 04:00:28PM +, Jonathan M Davis via Digitalmars-d wrote: > On Friday, 22 May 2015 at 14:11:49 UTC, H. S. Teoh wrote: > >+1, finally, something other than the usual bickering on the forum. > >;-) > > LOL. Don't worry. I'm sure that someone will come along and start > griping about something soon. > > :( > > Joking aside, we do seem to frequently have the problem that what we > have is good enough that folks expect it to be perfect and thus start > complaining about how we don't do something well enough when we > actually do it better than most anyone else. D certainly isn't perfect > - and we _do_ have areas to improve upon - but we what we do have is > pretty darn awesome. [...] Agreed, D does have its warts and dark corners, but overall it's extremely awesome. I just can't bring myself to starting new projects in any other language these days (unless I get paid to do it, of course). D has totally wrecked my life, and it's all yall's fault!! j/k T -- Why have vacation when you can work?? -- EC
Re: indie game contests
On Friday, 22 May 2015 at 16:24:18 UTC, Vlad Levenfeld wrote: I know there's a strong gamedev presence here, so I'm wondering if anyone's submitted any games written in D to any of these contests? What was your experience like? I'd like to enter one, and wonder if anyone would be interested in a collaboration. Outside of programming, I used to do low-poly 3d art (just as a hobby in my secondary school days), so I can potentially contribute visuals, and I'm pretty comfortable with openGL. From time to time I'm working on two smaller games, "Angry Snowball" (https://github.com/Dgame/AngrySnowball) and "Quinn Quadrat". I would like to present them, once they are ready, at "one game a month", but in the last few week I was busy with my studies. I would like to collaborate with you, but you should know that my pixel art is not that good. ;)
Re: std.allocator: FreeList uses simple statistics to control number of items
On Wednesday, 20 May 2015 at 17:28:50 UTC, Andrei Alexandrescu wrote: 1. How to update Pmiss efficiently? Most allocations should be fast, so it shouldn't be update with every call to allocate(). What I have now is I update every K calls. A one-pole low pass filter is a very efficient moving average. https://github.com/D-Programming-Language/druntime/blob/6e55b7aaff7566d374c2f253f831d3489e7fd1a5/src/gc/gc.d#L1732 Feed it with 1 on hit and 0 on miss to get Phit on average.
indie game contests
I know there's a strong gamedev presence here, so I'm wondering if anyone's submitted any games written in D to any of these contests? What was your experience like? I'd like to enter one, and wonder if anyone would be interested in a collaboration. Outside of programming, I used to do low-poly 3d art (just as a hobby in my secondary school days), so I can potentially contribute visuals, and I'm pretty comfortable with openGL.
Re: std.allocator: FreeList uses simple statistics to control number of items
On Wednesday, 20 May 2015 at 17:28:50 UTC, Andrei Alexandrescu wrote: There is a bothersome issue with freelists fronting general-purpose allocators (https://en.wikipedia.org/wiki/Free_list): they can grow indefinitely. Because they keep memory allocated in their parent, they cause fragmentation to it. You can look at jemalloc which has a GC algorithm for this problem. https://m.facebook.com/notes/facebook-engineering/scalable-memory-allocation-using-jemalloc/480222803919
Re: shared libs for OSX
On Thursday, 21 May 2015 at 01:31:37 UTC, bitwise wrote: I've been reading over all the bugs and conversations I can find, but I'm still confused about exactly what's going on here. What I need: -load a dynamic library on OSX using dlopen or Runtime.loadLibrary -use dlsym to retrieve my functions and set up a gc proxy Forget about the GC proxy, it's a hack to work around ODR issues. What you really need is a shared phobos library as we have on linux or freebsd. -pull interfaces of classes defined in the dynamic library into my program for use. If you want to exchange data and code across multiple shared libraries and your executable the runtime must be fully aware of all shared libraries to support casting ,exceptions and finalizers.
Re: shared libs for OSX
On Thursday, 21 May 2015 at 08:07:49 UTC, Jacob Carlborg wrote: I don't think anyone is working on this. Native TLS is a prerequisite which requires changes both to the compiler and the runtime. There's an enhancement request for native TLS [1]. One could also make emulated TLS work with shared libraries.
Re: shared libs for OSX
On Wednesday, 20 May 2015 at 21:35:38 UTC, bitwise wrote: Heh.. That's pretty useless. Any idea on the state of things? Like if there are plans to support this in the near future(few months)? I couldn't find many conversations on this. This kinda-totally ruins my plans(on OSX at least). Have you tried LDC? They recently got shared library support, maybe also on OSX.
Re: Uphill
On Friday, 22 May 2015 at 14:11:49 UTC, H. S. Teoh wrote: +1, finally, something other than the usual bickering on the forum. ;-) LOL. Don't worry. I'm sure that someone will come along and start griping about something soon. :( Joking aside, we do seem to frequently have the problem that what we have is good enough that folks expect it to be perfect and thus start complaining about how we don't do something well enough when we actually do it better than most anyone else. D certainly isn't perfect - and we _do_ have areas to improve upon - but we what we do have is pretty darn awesome. - Jonathan M Davis
Re: shared libs for OSX
On Thursday, 21 May 2015 at 15:51:38 UTC, bitwise wrote: I'm not sure exactly what you mean about "integrated runtime". I think he means Phobos/Druntime as shared library. Looking in /usr/share/dmd/lib, I see phobos as a static library (which I'm assuming includes druntime, which I don't see anywhere). If the runtime is linked as a static library, shouldn't it be able to link to a dynamic library and just work? I think a separate runtime is what I was expecting. Yes separate shared libraries (with multiple runtimes) work on every other platform. The problem for OSX is that onAddImage gets called for the executable and every shared library. It would be trivial to only register the image containing the current runtime, by comparing the address of a private symbol with the memory region of the images. https://github.com/D-Programming-Language/druntime/blob/6331ab1ae19f3ff82449a5734b59d81b128685f4/src/rt/sections_osx.d#L186
Re: Uphill
On Friday, 22 May 2015 at 10:21:18 UTC, Chris wrote: I was recently thinking that D is a bit like climbing up a hill or a mountain. For the most part you are focused on reaching the top, yet every once in a while it's good to stop and turn around to enjoy the scenery and see how far you've come. So here is what I see: - LDC/GDC: easy to download and use. Nicely packaged. - DUB: great tool for project management - DVM: great tool for upgrading from D to D. - Phobos: has become quite a useful library. Ranges are an important part of data processing, I don't wanna miss 'em anymore - vibe.d: a web server in D. - Projects in D: LuaD, PyD etc etc. - the expertise that's involved [add anything you like] Mind you, this has been achieved without millions of dollars and corporate backing and yet D is a real language with real applications (only nobody talks about it). I know, there is still a steep climb ahead of D, but let's enjoy the view for a while. What has been achieved is by no means trivial. Fully agreed, D is an interesting phenomena that makes everyone of my days happier :) Now, can we have OSX shared libraries please? :O
Re: Uphill
On Fri, May 22, 2015 at 10:21:17AM +, Chris via Digitalmars-d wrote: > I was recently thinking that D is a bit like climbing up a hill or a > mountain. For the most part you are focused on reaching the top, yet > every once in a while it's good to stop and turn around to enjoy the > scenery and see how far you've come. So here is what I see: > > - LDC/GDC: easy to download and use. Nicely packaged. > - DUB: great tool for project management > - DVM: great tool for upgrading from D to D. > - Phobos: has become quite a useful library. Ranges are an important > part of data processing, I don't wanna miss 'em anymore > - vibe.d: a web server in D. > - Projects in D: LuaD, PyD etc etc. > - the expertise that's involved > [add anything you like] > > Mind you, this has been achieved without millions of dollars and > corporate backing and yet D is a real language with real applications > (only nobody talks about it). I know, there is still a steep climb > ahead of D, but let's enjoy the view for a while. What has been > achieved is by no means trivial. +1, finally, something other than the usual bickering on the forum. ;-) T -- Nobody is perfect. I am Nobody. -- pepoluan, GKC forum
Re: std.regex replaceFirst vs. replaceFirstInto
On Friday, 22 May 2015 at 12:47:18 UTC, Liam McSherry wrote: On Friday, 22 May 2015 at 12:40:03 UTC, Chris wrote: Excuse my ignorance, but how do I file a bug on bugzilla? http://wiki.dlang.org/Get_involved#File_a_bug_report Thanks. Here it is: https://issues.dlang.org/show_bug.cgi?id=14615
Re: std.regex replaceFirst vs. replaceFirstInto
On Friday, 22 May 2015 at 12:40:03 UTC, Chris wrote: Excuse my ignorance, but how do I file a bug on bugzilla? http://wiki.dlang.org/Get_involved#File_a_bug_report
Re: std.regex replaceFirst vs. replaceFirstInto
On Friday, 22 May 2015 at 11:08:38 UTC, Chris wrote: On Friday, 22 May 2015 at 11:02:12 UTC, Dmitry Olshansky wrote: On 21-May-2015 14:51, Chris wrote: std.regex.replaceFirst uses https://github.com/D-Programming-Language/phobos/blob/master/std/regex/package.d#L734 which returns the input, if no match is found. This is "safe", because the worst thing that can happen is that you get the input back unchanged. std.regex.replaceFirstInto, on the other hand, uses https://github.com/D-Programming-Language/phobos/blob/master/std/regex/package.d#L700 which may throw an exception like this: phobos/std/regex/package.d(993): invalid submatch number 1* Shouldn't this be reflected in the documentation? At the moment, the documentation of replaceFirstInto says: "A variation on replaceFirst that instead of allocating a new string on each call outputs the result piece-wise to the sink." But it doesn't mention the difference in behavior (i.e. return input vs. exception). In other words, with replaceFirstInto, you have to make sure that you can indeed replace. The same probably goes for replaceAll / replaceAllInto. *Exception stems from https://github.com/D-Programming-Language/phobos/blob/master/std/regex/package.d#L962 Looks like a bug, no need to document this - please post it to bugzilla. A simple test case would help fixing it. Thanks! Ok. Do you have a link for me? Excuse my ignorance, but how do I file a bug on bugzilla?
Re: Uphill
On Friday, 22 May 2015 at 10:21:18 UTC, Chris wrote: I was recently thinking that D is a bit like climbing up a hill or a mountain. For the most part you are focused on reaching the top, yet every once in a while it's good to stop and turn around to enjoy the scenery and see how far you've come. So here is what I see: - LDC/GDC: easy to download and use. Nicely packaged. - DUB: great tool for project management - DVM: great tool for upgrading from D to D. - Phobos: has become quite a useful library. Ranges are an important part of data processing, I don't wanna miss 'em anymore - vibe.d: a web server in D. - Projects in D: LuaD, PyD etc etc. - the expertise that's involved [add anything you like] Mind you, this has been achieved without millions of dollars and corporate backing and yet D is a real language with real applications (only nobody talks about it). I know, there is still a steep climb ahead of D, but let's enjoy the view for a while. What has been achieved is by no means trivial. Well said! -- Paolo
Re: Uphill
On 22/05/2015 10:21 p.m., Chris wrote: I was recently thinking that D is a bit like climbing up a hill or a mountain. For the most part you are focused on reaching the top, yet every once in a while it's good to stop and turn around to enjoy the scenery and see how far you've come. So here is what I see: - LDC/GDC: easy to download and use. Nicely packaged. - DUB: great tool for project management - DVM: great tool for upgrading from D to D. - Phobos: has become quite a useful library. Ranges are an important part of data processing, I don't wanna miss 'em anymore - vibe.d: a web server in D. s/web server/web server framework/ My only gripe! - Projects in D: LuaD, PyD etc etc. - the expertise that's involved [add anything you like] Mind you, this has been achieved without millions of dollars and corporate backing and yet D is a real language with real applications (only nobody talks about it). I know, there is still a steep climb ahead of D, but let's enjoy the view for a while. What has been achieved is by no means trivial.
Re: std.regex replaceFirst vs. replaceFirstInto
On Friday, 22 May 2015 at 11:02:12 UTC, Dmitry Olshansky wrote: On 21-May-2015 14:51, Chris wrote: std.regex.replaceFirst uses https://github.com/D-Programming-Language/phobos/blob/master/std/regex/package.d#L734 which returns the input, if no match is found. This is "safe", because the worst thing that can happen is that you get the input back unchanged. std.regex.replaceFirstInto, on the other hand, uses https://github.com/D-Programming-Language/phobos/blob/master/std/regex/package.d#L700 which may throw an exception like this: phobos/std/regex/package.d(993): invalid submatch number 1* Shouldn't this be reflected in the documentation? At the moment, the documentation of replaceFirstInto says: "A variation on replaceFirst that instead of allocating a new string on each call outputs the result piece-wise to the sink." But it doesn't mention the difference in behavior (i.e. return input vs. exception). In other words, with replaceFirstInto, you have to make sure that you can indeed replace. The same probably goes for replaceAll / replaceAllInto. *Exception stems from https://github.com/D-Programming-Language/phobos/blob/master/std/regex/package.d#L962 Looks like a bug, no need to document this - please post it to bugzilla. A simple test case would help fixing it. Thanks! Ok. Do you have a link for me?
Re: std.regex replaceFirst vs. replaceFirstInto
On 21-May-2015 14:51, Chris wrote: std.regex.replaceFirst uses https://github.com/D-Programming-Language/phobos/blob/master/std/regex/package.d#L734 which returns the input, if no match is found. This is "safe", because the worst thing that can happen is that you get the input back unchanged. std.regex.replaceFirstInto, on the other hand, uses https://github.com/D-Programming-Language/phobos/blob/master/std/regex/package.d#L700 which may throw an exception like this: phobos/std/regex/package.d(993): invalid submatch number 1* Shouldn't this be reflected in the documentation? At the moment, the documentation of replaceFirstInto says: "A variation on replaceFirst that instead of allocating a new string on each call outputs the result piece-wise to the sink." But it doesn't mention the difference in behavior (i.e. return input vs. exception). In other words, with replaceFirstInto, you have to make sure that you can indeed replace. The same probably goes for replaceAll / replaceAllInto. *Exception stems from https://github.com/D-Programming-Language/phobos/blob/master/std/regex/package.d#L962 Looks like a bug, no need to document this - please post it to bugzilla. A simple test case would help fixing it. Thanks! -- Dmitry Olshansky
Re: Dconf Video / Projector Information
On Wednesday, 20 May 2015 at 22:14:56 UTC, Adam D. Ruppe wrote: Also, when are the videos going to be released this time? I'd like it on youtube as soon as possible. That would be great! +1
Uphill
I was recently thinking that D is a bit like climbing up a hill or a mountain. For the most part you are focused on reaching the top, yet every once in a while it's good to stop and turn around to enjoy the scenery and see how far you've come. So here is what I see: - LDC/GDC: easy to download and use. Nicely packaged. - DUB: great tool for project management - DVM: great tool for upgrading from D to D. - Phobos: has become quite a useful library. Ranges are an important part of data processing, I don't wanna miss 'em anymore - vibe.d: a web server in D. - Projects in D: LuaD, PyD etc etc. - the expertise that's involved [add anything you like] Mind you, this has been achieved without millions of dollars and corporate backing and yet D is a real language with real applications (only nobody talks about it). I know, there is still a steep climb ahead of D, but let's enjoy the view for a while. What has been achieved is by no means trivial.
Re: Dconf Video / Projector Information
On Wednesday, 20 May 2015 at 22:14:56 UTC, Adam D. Ruppe wrote: Also, when are the videos going to be released this time? I'd like it on youtube as soon as possible. +1
Re: Request for Features/Ideas: A std.archive package
On 22/05/2015 7:57 p.m., FreeSlave wrote: On Thursday, 21 May 2015 at 09:16:47 UTC, John Colvin wrote: On Thursday, 21 May 2015 at 08:55:05 UTC, Jacob Carlborg wrote: On 2015-05-21 00:46, Walter Bright wrote: Clearly, we need a Deimos entry for libarchive. https://github.com/d-programming-deimos No, it needs to be a Dub package. Can we please kill Deimos. Most (all?) deimos repositories are dub packages. Actually only few deimos bindings have dub packages. Seems like It's supposed to just copy the code to your project, which is not very nice. Deimos is pre dub. Really deimos as a concept can be stopped now. Also, out of topic, is there a way to propose binding to deimos? Did not find anything on that.
Re: Request for Features/Ideas: A std.archive package
On Thursday, 21 May 2015 at 09:16:47 UTC, John Colvin wrote: On Thursday, 21 May 2015 at 08:55:05 UTC, Jacob Carlborg wrote: On 2015-05-21 00:46, Walter Bright wrote: Clearly, we need a Deimos entry for libarchive. https://github.com/d-programming-deimos No, it needs to be a Dub package. Can we please kill Deimos. Most (all?) deimos repositories are dub packages. Actually only few deimos bindings have dub packages. Seems like It's supposed to just copy the code to your project, which is not very nice. Also, out of topic, is there a way to propose binding to deimos? Did not find anything on that.
