Re: The worst Phobos template (in binderoo)
On Wednesday, 14 September 2016 at 20:24:13 UTC, Stefan Koch wrote: I would like to see users of fullyQualifiedName because apart from binderoo code which seems to work, I have none. I've had to use fullyQualifiedName in some string mixins. Take a look at https://github.com/BlackEdder/painlessjson/blob/9f9b94b3a47ada4ffdea16ef5dc5476c74cb9a06/source/painlessjson/painlessjson.d#L415. I also recommend using GitHub search to find other examples.
Re: Regex in ctfe?
On Tuesday, 26 January 2016 at 12:47:26 UTC, w0rp wrote: Unless I'm mistaken, I think the compiler for regex currently works at compile time, but not the matcher. Maybe someone who knows the module could add support for that. That's correct. I looked in to this a while ago and found out that the matcher uses @trusted code with pointers. Getting support for ctfe would require a rewrite of most of the matching engine and would probably result in a rather big performance hit.
Re: Better lambdas!!!!!!!!!!
On Saturday, 12 September 2015 at 03:32:51 UTC, Prudence wrote:
On Saturday, 12 September 2015 at 02:13:11 UTC, Pierre Krafft
wrote:
On Saturday, 12 September 2015 at 01:03:54 UTC, Prudence wrote:
On Thursday, 10 September 2015 at 18:02:36 UTC, Ali Çehreli
wrote:
On 09/10/2015 10:55 AM, Prudence wrote:
> How bout this:
>
> void myfunc(double delegate(int i, int z, float f)) {}
>
>
> myfunc((int i, int z, float f) { return i*z*f; } }
>
> vs
>
> myfunc({ return i*z*f; }) // Names of parameters are
inferred from
> signature.
Considering other features of the language, that's pretty
much impossible in D. What if there is another i in scope:
int i;
myfunc({ return i*z*f; });
Now, should it call another overload of myfunc that takes
(int z, int f) because i is something else?
Should the compiler analyze the body of the code and decide
which symbols could be parameters? And then go through all
overloads of myfunc? etc.?
Ali
As I said, it could throw a warning or error. It, in some
sense, is already a a problem with nested blocks that hide
outside variables, is it not?
The compiler doesn't need to scan anything. It knows the
which parameters from the definition!
-> void myfunc(double delegate(int i, int z, float f)) <-
Compiler knows to use the names here as the default names in
for the parameters when.
when used:
myfunc({ return i*z*f; }); <- Oh, there are the names, we
know what they are because the signature is tells us. The
compiler does the following:
1. Sees we have a block without any parameters defined. i.e.,
a lambda.
2. It looks up the signature of myfunc to find out what the
names are
3. It sees that they are i z and f
4. Now it knows and it effectively rewrites the code as
myfunc((i,z,f) { return i*z*f; });
Surely this is not difficult, 4 steps?
You're making your code more brittle for a small gain. The
suggestion makes parameter usage order important and the
compiler can't warn about my typos.
Consider:
myfunc({return "x:"~x~"y:"-y;}) getting changed to
myfunc({return "y:"~y~"x:"~x;});
Or the typo in
myfunc({return i*z+f*j;});
Lambdas are already very concise. This proposal doesn't give
any benefits outside of very simple lambdas. Such lambdas are
already so simple that they could use some standard functions
instead (like sum, to!T, and bind).
What does this have to do with my proposal? Those issues exist
regardless of the simplification.
myfunc({return "x:"~x~"y:"-y;}) getting changed to
myfunc({return "y:"~y~"x:"~x;});
huh? What do you mean the suggestion makes parameter usage
order important? They are important, it has nothing to do with
the suggestion? Are you saying that you want to reserve the
right to do something like
myfunc(string delegate(string x, string y));
and
myfunc((y,x){ "y:"~y~"x:"~x; })
? If so, or unless I'm missing something, that's bad no matter
what. Changing the order and reversing the names is more than
just confusing, it's hard to read and most people will gloss
over that fact. Be consistent with your parameters and maybe
you'll have less bugs?
Or the typo in
myfunc({return i*z+f*j;});
Again, what does this have to do with anything? A typo is a
typo and is always a mistake. The above example has the same
effect regardless if the parameters are explicit or deduced.
myfunc((i,z,f) {return i*z+f*j;});
j is still a problem. If j is defined outside the lambda then
regardless of specific or implicit parameter names, it will not
cause any problems.
In either case, the compiler can see that j is either
referenced outside the scope or undefined. It has nothing to do
with the parameters used.
Of course maybe I'm missing something, but essentially are not
almost all uses of lambda's simply copying the parameter
signature of the delegate. It already infers types... you could
say that leads to typo's too...
myfunc({return "x:"~x~"y:"-y;});
is infered to mean myfunc((x,y){return "x:"~x~"y:"-y;});
while
myfunc({return "y:"~y~"x:"~x;});
is infered to mean myfunc((y,x){return "y:"~y~"x:"~x;});
which is not what I expect since the lambda I want is
myfunc((x,y){return "y:"~y~"x:"~x;});
This can lead to subtle bugs which are very hard to see.
In the typo example there could be two overloaded functions
differing only in that one takes a delegate having 3 parameters
and one taking a delegate having 4 parameters. If we explicitly
write the lambda parameters the typo will be found since j is
undefined. But when parameters are inferred the compiler will see
that {return i*z + f*j;} matches the function taking a lambda
with 4 parameters.
Inferred parameter types are on the brink of what I can allow.
They can risk typos, but not as easily since you write the
parameters twice (declaration and usage). They can also silently
change if the function taking the delegate has the parameter type
changed. I don't want to add more magic to that area.
Re: Better lambdas!!!!!!!!!!
On Saturday, 12 September 2015 at 01:03:54 UTC, Prudence wrote:
On Thursday, 10 September 2015 at 18:02:36 UTC, Ali Çehreli
wrote:
On 09/10/2015 10:55 AM, Prudence wrote:
> How bout this:
>
> void myfunc(double delegate(int i, int z, float f)) {}
>
>
> myfunc((int i, int z, float f) { return i*z*f; } }
>
> vs
>
> myfunc({ return i*z*f; }) // Names of parameters are
inferred from
> signature.
Considering other features of the language, that's pretty much
impossible in D. What if there is another i in scope:
int i;
myfunc({ return i*z*f; });
Now, should it call another overload of myfunc that takes (int
z, int f) because i is something else?
Should the compiler analyze the body of the code and decide
which symbols could be parameters? And then go through all
overloads of myfunc? etc.?
Ali
As I said, it could throw a warning or error. It, in some
sense, is already a a problem with nested blocks that hide
outside variables, is it not?
The compiler doesn't need to scan anything. It knows the which
parameters from the definition!
-> void myfunc(double delegate(int i, int z, float f)) <-
Compiler knows to use the names here as the default names in
for the parameters when.
when used:
myfunc({ return i*z*f; }); <- Oh, there are the names, we know
what they are because the signature is tells us. The compiler
does the following:
1. Sees we have a block without any parameters defined. i.e., a
lambda.
2. It looks up the signature of myfunc to find out what the
names are
3. It sees that they are i z and f
4. Now it knows and it effectively rewrites the code as
myfunc((i,z,f) { return i*z*f; });
Surely this is not difficult, 4 steps?
You're making your code more brittle for a small gain. The
suggestion makes parameter usage order important and the compiler
can't warn about my typos.
Consider:
myfunc({return "x:"~x~"y:"-y;}) getting changed to myfunc({return
"y:"~y~"x:"~x;});
Or the typo in
myfunc({return i*z+f*j;});
Lambdas are already very concise. This proposal doesn't give any
benefits outside of very simple lambdas. Such lambdas are already
so simple that they could use some standard functions instead
(like sum, to!T, and bind).
Re: std.json questions
On Saturday, 25 April 2015 at 18:30:33 UTC, Baz wrote: On Saturday, 25 April 2015 at 09:56:25 UTC, tired_eyes wrote: I think this is ugly and clunky approach, what is the beautiful one? What you clearly need is a serializer: look at these: http://wiki.dlang.org/Libraries_and_Frameworks#Serialization and also: https://github.com/search?utf8=✓q=serializer+language%3ADtype=Repositoriesref=searchresults some of them might have an API to save load an object or a struct in a single call. Also http://code.dlang.org/search?q=json
Re: Future of contract-based programming in D
On Wednesday, 8 April 2015 at 11:26:38 UTC, Kagamin wrote: BTW, what do you think about this problem: http://forum.dlang.org/post/cokicokwqnscaktxi...@forum.dlang.org ? That's a great feature! Don't inherit if it's not the right tool, and it almost never is. We have interfaces and alias this with @disable so composition is really easy to do. I am starting to think that when we have multiple alias this we would be better of if we stopped using inheritance at all. Except for the syntax I can't come up with a problem that would be better solved using inheritance than using composition.
Re: Which D IDE do you use?(survey)
Any editor using DCD will be great, and I think most D editors are. I use Sublime exclusively since it's easy to setup and effective for me to use.
Re: Future of contract-based programming in D
On Wednesday, 8 April 2015 at 12:13:00 UTC, Kagamin wrote: On Wednesday, 8 April 2015 at 12:07:18 UTC, Pierre Krafft wrote: Except for the syntax I can't come up with a problem that would be better solved using inheritance than using composition. How would you interate a collection of widgets without polymorphism, i.e. any generic handling? I mention the tool I use in the post. On Wednesday, 8 April 2015 at 12:07:18 UTC, Pierre Krafft wrote: We have interfaces and alias this with @disable so composition is really easy to do. So use a collection of interface instead of a collection of base class. If you squint you could say that what I promote is a way of doing inheritance, and I would agree. This is like doing inheritance, with a bit worse syntax but with greater flexibility.
Re: Mid-term vision review
On Tuesday, 7 April 2015 at 08:01:19 UTC, Dicebot wrote: On Monday, 6 April 2015 at 18:17:31 UTC, deadalnix wrote: On the other hand, many features in the language could be implementation as macro in object.d, reducing language complexity. Mixin has some severe limitation when you want to pass symbols that are not accessible down the road (the type mechanism in SDC is a very good example of how absurdly complex things can get just because you need to make some symbols accessible down the road). I'm not eager to see them in, as I'd favor finishing what is already started. Over time, while researching how macro approach feels like in other languages, I have become more sceptical of providing it as a generally available feature. But it could be interesting to allow them only in std / core package to be able to move more language implementation into library. My opinion is that it should be addressed as a culture problem and not trying to limit the language. If a macro-system could be added it shouldn't be limited to just phobos code. Instead the community should look down upon over usage of the feature in non-library code.
Re: Making regex replace CTFE by removing malloc
I got some help from the IRC, poked the code a bit and have some details I can share. The code uses a reference counted memory pool, that's the part I linked. It's possible to avoid the malloc but that's not the hard part. For me it looks like memory pools aren't compatible with CTFE. This is because CTFE disallows most pointer casts. Allocations and frees have fortunately been moved to common functions so it should be possible to change the allocation code without too much hassle. I would prefer to have the same code for runtime and CTFE, but for performance reasons that might not be possible if CTFE has a too limited feature set. I think a good idea would be to extract the memory pool code out of the regex module. It's not a core part of the problem and could be reused elsewhere. Having something named memory pool would also make the code clearer. It might be impossible to implement memory pools at CTFE so we could hide that detail away by simulating a memory pool (at CTFE) until it becomes possible. The code in general is quite clear, but low level and more about how to do it than what to do. This is not the D-style I know and love, but it might be needed for performance. Therefore I probably won't be the one that starts the implementation of this, but I will try to help if someone more experienced in this kind of code takes action.
Re: Making regex replace CTFE by removing malloc
On Friday, 3 April 2015 at 03:58:33 UTC, ketmar wrote: On Thu, 02 Apr 2015 17:14:24 +, Pierre Krafft wrote: What can replace malloc that can run on compile time and won't make it slower at run time? this is actually two questions, so i'll answer to two questions. 1. What can replace malloc that can run on compile time? new ubyte[](size) 2. ...and won't make it slower at run time? but we can still use malloc in runtime! `if (_ctfe)` allows us to select the necessary code branch. p.s. i don't think that this is the only problem, though. but i never read std.regexp source. it's bad, 'cause i want to make it work with any range, not only with strings. this will allow to run regexp on anything -- and open way to my rbtree-based document system. Thanks! I'll take a look and see if I can make it work.
Re: Making regex replace CTFE by removing malloc
On Friday, 3 April 2015 at 03:58:33 UTC, ketmar wrote: On Thu, 02 Apr 2015 17:14:24 +, Pierre Krafft wrote: What can replace malloc that can run on compile time and won't make it slower at run time? this is actually two questions, so i'll answer to two questions. 1. What can replace malloc that can run on compile time? new ubyte[](size) 2. ...and won't make it slower at run time? but we can still use malloc in runtime! `if (_ctfe)` allows us to select the necessary code branch. p.s. i don't think that this is the only problem, though. but i never read std.regexp source. it's bad, 'cause i want to make it work with any range, not only with strings. this will allow to run regexp on anything -- and open way to my rbtree-based document system. It seems like I have treaded into something which is outside my knowledge domain. The malloc is indeed one of the least problems with that code. The code makes use of completely unsafe code with pointer casts that are disallowed in CTFE code. If someone knows how to replace the pointer casts that would probably be everything needed. Otherwise I think it would need a rewrite to make it use safe D. The new code would probably be slower so for most people it would be a step back. A solution would be to have different code for CTFE and runtime but that seems unmaintainable and subpar.
Re: How to POST data with net.curl
On Thursday, 2 April 2015 at 07:45:16 UTC, Suliman wrote:
I have next request, that work fine with curl:
curl -X POST -F upload=@wgs84_latlon.zip
http://ogre.adc4gis.com/convert
I wrote next code:
void main()
{
auto binfile = cast(ubyte[])
read(`D:\Apps\curl\wgs84_latlon.zip`);
auto http = HTTP(http://ogre.adc4gis.com/convert;);
http.setPostData(binfile, -X POST -F upload=@);
http.onReceive = (ubyte[] data) { writeln((cast(string)data));
return data.length; };
http.perform();
}
But I have got trouble with http.setPostData. I do not know how
to properly write text part, and attaches binary zip file.
I had trouble with that too. Take a look at
https://github.com/Zalastax/AvanzaFundSimulator/blob/master/source/funds/fundfetcher.d
and
https://github.com/Zalastax/zalastaxlibd/blob/master/source/std/extra/http.d
to see if that can help.
Making regex replace CTFE by removing malloc
We have CTFE regex wich creates an optimized regex engine at
compile time. I would want to expand on that and make the
generated machine CTFE as well. I think the only thing that is
stopping this from working is the use of malloc as seen at
https://github.com/D-Programming-Language/phobos/blob/cb044b02aa3abd0bddc5e48a91faebfd146cab3e/std/regex/package.d#L565
What can replace malloc that can run on compile time and won't
make it slower at run time?
Here is an example of what I would want to work:
unittest {
enum hello_world = camelCaseToUnderscore(helloWorld);
assertEqual(hello_world, hello_world);
}
private string camelCaseToUnderscore(string input){
import std.regex;
auto ctr = ctRegex!(`([a-z])([A-Z])`);
auto replaceString = $1_$2;
return replaceAll(input, ctr, replaceString).toLower();
}
Re: painlessjson released, looking for improvement advice
On Sunday, 1 February 2015 at 06:08:35 UTC, Vladimir Panteleev wrote: On Thursday, 29 January 2015 at 20:04:51 UTC, Pierre Krafft wrote: It's fun to see that there are so many different solutions to working with JSON in D. jsvar seems to be for keeping your variables in JavaScript-land, something I think is a bad idea in most cases. The idea of painlessjson is to convert to native D as fast as possible. The goal is to get something like https://github.com/FasterXML/jackson for D. We are still looking for input on how inheritance and constructors should work. This is nothing new, I believe Vibe.d has a similar JSON (de)serializer. Here's my own: https://github.com/CyberShadow/ae/blob/master/utils/json.d Too slow? Try this one instead: https://github.com/CyberShadow/ae/blob/master/utils/serialization/json.d (Caveat: last one needs 5-ish compiler patches to work.) You are right. My intention is not to make it seem like this is new or revolutionary. The intention is to get some input on the work and hopefully provide a solution that in the end will be well documented, easy to find, and easy to integrate with. I don't know why I didn't find the one in vibe.d but it's still bundled with a lot else and uses it's own JSON implementation. Painlessjon was the only library I could find on Github when searching for JSON that I could get working. Almost every library provided their own instead of using std.json.If std.json is bad it should be improved to help everyone using it. The D community need to be better at putting their work on DUB and to separate their libraries more. I know that there are many tools out there that is not fully utilized because it's so hard to find them. I will continue working on painlessjson and will take a look on the implementations I have now found and try to take the best from them. I have already seen some things in your code that I can make use of.
Re: painlessjson released, looking for improvement advice
On Thursday, 29 January 2015 at 13:16:48 UTC, BlackEdder wrote:
On Thursday, 29 January 2015 at 00:24:44 UTC, rlonstein wrote:
Not quite the same, but I've been using dson
(https://github.com/w0rp/dson).
Have you looked it over?
Did not know about that one. From looking through the source it
seems to have a different goal though. dson looks like it is an
alternative to std.json. Painlessjson is meant to make it
easier to use json, by automatically (de)serializing
objects/structs and converting them to (and from) json.
For example:
class Point
{
double x;
double y;
}
void main()
{
auto pnt = new Point( 1,2 );
auto jsonPnt = toJSON( pnt ); // Returns a JSONValue( { x:
1.0, y: 2.0 } )
auto nPnt = fromJSON!Point( jsonPnt );
assert( nPnt.x == pnt.x nPnt.y == pnt.y );
}
I guess it would be interesting to use dson instead of std.json
as a basis for Painlessjson.
I believe we should continue using std.json, and instead push for
taking dson (or its lessons learned) into phobos if it's a better
implementation. The best general solution should be the one that
is available out of the box.
Re: painlessjson released, looking for improvement advice
On Thursday, 29 January 2015 at 18:47:37 UTC, Rory McGuire wrote: :) I use jsvar for any JSON work in D. Javascript is the only thing I've used that is possibly easier to work with JSON values. https://github.com/adamdruppe/arsd/blob/master/jsvar.d On Thu, Jan 29, 2015 at 5:18 PM, BlackEdder via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On Thursday, 29 January 2015 at 14:05:25 UTC, Chris wrote: Yeah, I was wondering, if you have to import std.json and use it as a basis for painlessjson, is it really so big an improvement? Especially since std.json might be replaced (sooner or later). I'd prefer an easy to use implementation that replaces std.json completely. Painlessjson in many ways abstracts away the std.json implementation, so using it you should rarely/never have to use std.json directly. It basically abstracts away most of the complexity and you should only ever have to use toJSON and fromJSON. This works with built-in types (double/int/string etc.) and also with ranges and associative arrays. On top of that Painlessjson also makes it easy to convert your own types/struct/classes to and from JSON by (de)serializing them automatically (as far as possible). If a better simpler std.json gets developed then we can rebase painlessjson on that and it might become a thinner wrapper, but I would expect the (de)serialization still to be useful in many cases. It's fun to see that there are so many different solutions to working with JSON in D. jsvar seems to be for keeping your variables in JavaScript-land, something I think is a bad idea in most cases. The idea of painlessjson is to convert to native D as fast as possible. The goal is to get something like https://github.com/FasterXML/jackson for D. We are still looking for input on how inheritance and constructors should work.
painlessjson released, looking for improvement advice
Hi,
DUB lacked a package for going between D objects and JSON.
painlessjson is a library just released on DUB looking to be the
easy solution for converting D data to and from JSON.
painlessjson uses templates and traits to generate code that
converts to and from std.json.
The goals of painlessjson are:
- Easy to use and set up
- Highly configurable with sensible defaults
- Keep the library code simple by not reinventing what others
provide for us
- Support as many D types as possible
Current features are:
- Convert to and from std.json, structs and classes with default
constructor, arrays, associative arrays, and any type
implementing _toJSON + _fromJSON.
- Includes @property functions
- Ignore a field using @SerializeIgnore
- Rename a field using @SerializedName(Name) or
@SerializedToName('To') @SerializedFromName('From')
This project gained momentum just recently so there are several
things to improve. We want input and help to make this as great
as possible.
The features that are being designed right now are quite tricky
to get right so any help would be greatly appreciated.
The project is on github:
https://github.com/BlackEdder/painlessjson
And on DUB: http://code.dlang.org/packages/painlessjson
Our current issues are:
- How do we support subclasses?
https://github.com/BlackEdder/painlessjson/issues/8
- How should constructors be handled? Don't forget alias this and
preferably find the best constructor to use without relying on
annotations. https://github.com/BlackEdder/painlessjson/issues/12
