Re: Article: D Exceptions and C Callbacks
Am Wed, 07 Aug 2013 12:08:44 +0200 schrieb Mike Parker aldac...@gmail.com: On Wednesday, 7 August 2013 at 07:10:21 UTC, Johannes Pfau wrote: Am Wed, 07 Aug 2013 03:33:28 +0200 schrieb Mike Parker aldac...@gmail.com: Maybe modifying glfwSetWindowCloseCallback and similar functions to only accept nothrow functions is a good idea? I'm not sure what you mean. That's a C function, which means it doesn't have any concept of D's nothrow. And, actually, the callbacks should be declared as nothrow anyway. Like: He meant declaring glfwSetWindowCloseCallback like this: alias extern(C) nothrow void function() callback; extern(C) void glfwSetWindowCloseCallback(callback cb); http://dpaste.dzfl.pl/0f23146f There's no difference in the generated code, but this way the compiler will complain if you pass a non-nothrow function to glfwSetWindowCloseCallback. Yeah, I see. I misunderstood. I agree that the callbacks should be declared as nothrow. In Derelict, all the C function pointers are declared as such. Apparently, I overlooked adding it to the callbacks. I recently proposed using nothrow in GtkD as well. This article was kind of a coincidence now. Yes, it is a real issue with binding to C code unfortunately. Especially on amd64 with GCC compiled stuff since it omits the stack frame that DMD requires to unwind the stack resulting in immediate crashes (druntime HLTs the execution) as soon as you throw an exception from a callback. -- Marco
Re: Article: D Exceptions and C Callbacks
On 8/8/2013 6:48 AM, Marco Leise wrote: I recently proposed using nothrow in GtkD as well. This article was kind of a coincidence now. Yes, it is a real issue with binding to C code unfortunately. Especially on amd64 with GCC compiled stuff since it omits the stack frame that DMD requires to unwind the stack resulting in immediate crashes (druntime HLTs the execution) as soon as you throw an exception from a callback. I agree that C callbacks called from C code should be nothrow. At a minimum, the C code that calls the callback is not going to be expecting an exit via exception, and so may leave things in an indeterminate state.
A new blog article detailing the alternative function syntax
I've just finished a new blog article on the subject of alternative function syntax in D. I guess this is pretty straightforward stuff to all the people here but was a major source of confusion to me (and others?) when first learning D. I personally think this is more confusing than many people think. Hopefully this will quickly arm a developer with knowledge to be able to read and understand most D code. Let me know if i've missed anything important. http://nomad.so/2013/08/alternative-function-syntax-in-d/ I'll post to reddit in the morning.
Re: A new blog article detailing the alternative function syntax
On 8/8/2013 12:15 PM, Walter Bright wrote: s/compliments/complements/ The frequency with which I see this error is a pet peeve of mine!
Re: A new blog article detailing the alternative function syntax
On 8/8/2013 11:53 AM, Gary Willoughby wrote: I personally think this is more confusing than many people think. Hopefully this will quickly arm a developer with knowledge to be able to read and understand most D code. Let me know if i've missed anything important. http://nomad.so/2013/08/alternative-function-syntax-in-d/ s/compliments/complements/ s/-profile/-property/ s/behaviour/behavior/ if you mean to use the american english spelling s/explained the rules/explained that the rules/ s/ommited/omitted/ s/in the call parens/in the call then parens/ s/i've/I've/ Under Extension Methods, a huge reason for them is to head off the temptation to write 'kitchen sink' classes that are filled with every conceivable method. The desired approach is to have the class implement the bare minimum of functionality, and add other functionality with extension methods (that do not have access to the class' private state). All in all, good article!
Re: A new blog article detailing the alternative function syntax
On 8/8/13 3:53 PM, Gary Willoughby wrote: I've just finished a new blog article on the subject of alternative function syntax in D. I guess this is pretty straightforward stuff to all the people here but was a major source of confusion to me (and others?) when first learning D. I personally think this is more confusing than many people think. Hopefully this will quickly arm a developer with knowledge to be able to read and understand most D code. Let me know if i've missed anything important. http://nomad.so/2013/08/alternative-function-syntax-in-d/ I'll post to reddit in the morning. Nice article. But when I read alternative function syntax I thought your article was a proposal for that, an alternative function syntax. :-P Maybe it should be renamed to something else... but I don't know enough English to suggest that.
Re: A new blog article detailing the alternative function syntax
On Thursday, 8 August 2013 at 19:24:31 UTC, Ary Borenszweig wrote: On 8/8/13 3:53 PM, Gary Willoughby wrote: I've just finished a new blog article on the subject of alternative function syntax in D. I guess this is pretty straightforward stuff to all the people here but was a major source of confusion to me (and others?) when first learning D. I personally think this is more confusing than many people think. Hopefully this will quickly arm a developer with knowledge to be able to read and understand most D code. Let me know if i've missed anything important. http://nomad.so/2013/08/alternative-function-syntax-in-d/ I'll post to reddit in the morning. Nice article. But when I read alternative function syntax I thought your article was a proposal for that, an alternative function syntax. :-P Maybe it should be renamed to something else... but I don't know enough English to suggest that. Maybe unique instead of alternative?
Re: A new blog article detailing the alternative function syntax
On Thursday, 8 August 2013 at 19:15:29 UTC, Walter Bright wrote: lots... I've made the corrections, thanks. I really need to work on my English. I haven't written anything in years and it's harder work than i remember. Nothing that practise, practise, practise ...and a spell checker won't fix! ;)
Re: A new blog article detailing the alternative function syntax
On Thursday, 8 August 2013 at 18:53:47 UTC, Gary Willoughby wrote: I've just finished a new blog article on the subject of alternative function syntax in D. I guess this is pretty straightforward stuff to all the people here but was a major source of confusion to me (and others?) when first learning D. I personally think this is more confusing than many people think. Hopefully this will quickly arm a developer with knowledge to be able to read and understand most D code. Let me know if i've missed anything important. http://nomad.so/2013/08/alternative-function-syntax-in-d/ I'll post to reddit in the morning. I think you should mention the terms UFCS and IFTI, since those are used by D folk. UFCS: Universal Function Call Syntax, i.e. dot notation. IFTI: Implicit Function Template Instantiation, i.e. template parameters can be omitted when they can be deduced from the function arguments.
Re: GHC 2013 in Paris
On Thursday, 8 August 2013 at 19:25:45 UTC, Iain Buclaw wrote: On Monday, 22 July 2013 at 00:16:13 UTC, bioinfornatics wrote: I'm speaking on the 24th in the afternoon, so I guess you get what you wished for. :) I'll be there just in time for Hurd, and stay until the end of the day. Looking forward.
Re: Article: D Exceptions and C Callbacks
On 8/8/13, Walter Bright newshou...@digitalmars.com wrote: I agree that C callbacks called from C code should be nothrow. At a minimum, the C code that calls the callback is not going to be expecting an exit via exception, and so may leave things in an indeterminate state. What about Error and Throwable? I think those shouldn't pass to the C code either. Unforunately 'nothrow' is a misnomer because it really means 'noexception', it allows both Error and Throwable to propagate from nothrow functions.
Re: A new blog article detailing the alternative function syntax
On Thursday, 8 August 2013 at 20:37:35 UTC, anonymous wrote: I think you should mention the terms UFCS and IFTI, since those are used by D folk. UFCS: Universal Function Call Syntax, i.e. dot notation. IFTI: Implicit Function Template Instantiation, i.e. template parameters can be omitted when they can be deduced from the function arguments. Good point.
Re: A new blog article detailing the alternative function syntax
On Thursday, 8 August 2013 at 19:18:22 UTC, Walter Bright wrote: On 8/8/2013 12:15 PM, Walter Bright wrote: s/compliments/complements/ The frequency with which I see this error is a pet peeve of mine! I know! It's rediculous!
Re: A new blog article detailing the alternative function syntax
On Thursday, 8 August 2013 at 19:15:29 UTC, Walter Bright wrote: Under Extension Methods, a huge reason for them is to head off the temptation to write 'kitchen sink' classes that are filled with every conceivable method. The desired approach is to have the class implement the bare minimum of functionality, and add other functionality with extension methods (that do not have access to the class' private state). http://www.drdobbs.com/cpp/how-non-member-functions-improve-encapsu/184401197#.UW1X9HWZeXA.reddit I think you linked this Meyers article at some point as being the original rationale for UFCS (correct me if I'm wrong).
Re: A new blog article detailing the alternative function syntax
On 8/8/13 1:28 PM, Gary Willoughby wrote: On Thursday, 8 August 2013 at 19:15:29 UTC, Walter Bright wrote: lots... I've made the corrections, thanks. I really need to work on my English. I haven't written anything in years and it's harder work than i remember. Nothing that practise, practise, practise ...and a spell checker won't fix! ;) s/practise/practice/g :o) If you want me to post to reddit tomorrow morning, let me know. My good post karma is likely to push the post into visibility quickly. On the other hand, if you post it yourself it will improve _your_ karma. Tradeoffs, tradeoffs... Andrei
Re: A new blog article detailing the alternative function syntax
On 8/8/2013 3:02 PM, Brad Anderson wrote: On Thursday, 8 August 2013 at 19:15:29 UTC, Walter Bright wrote: Under Extension Methods, a huge reason for them is to head off the temptation to write 'kitchen sink' classes that are filled with every conceivable method. The desired approach is to have the class implement the bare minimum of functionality, and add other functionality with extension methods (that do not have access to the class' private state). http://www.drdobbs.com/cpp/how-non-member-functions-improve-encapsu/184401197#.UW1X9HWZeXA.reddit I think you linked this Meyers article at some point as being the original rationale for UFCS (correct me if I'm wrong). You're right. I was just too lazy to link to it myself. Thanks for doing it. BTW, I think that article is required reading. It's an easy read, and was an eye-opener for me.
Re: A new blog article detailing the alternative function syntax
On Thursday, 8 August 2013 at 18:53:47 UTC, Gary Willoughby wrote: I've just finished a new blog article on the subject of alternative function syntax in D. I guess this is pretty straightforward stuff to all the people here but was a major source of confusion to me (and others?) when first learning D. I personally think this is more confusing than many people think. Hopefully this will quickly arm a developer with knowledge to be able to read and understand most D code. Let me know if i've missed anything important. http://nomad.so/2013/08/alternative-function-syntax-in-d/ I'll post to reddit in the morning. The second non-member function example is part of the -property controversy. foo = 123; // called as foo(123) Not sure if you'd want that mentioned.
Re: Article: D Exceptions and C Callbacks
Am Thu, 08 Aug 2013 11:33:28 -0700 schrieb Walter Bright newshou...@digitalmars.com: On 8/8/2013 6:48 AM, Marco Leise wrote: I recently proposed using nothrow in GtkD as well. This article was kind of a coincidence now. Yes, it is a real issue with binding to C code unfortunately. Especially on amd64 with GCC compiled stuff since it omits the stack frame that DMD requires to unwind the stack resulting in immediate crashes (druntime HLTs the execution) as soon as you throw an exception from a callback. I agree that C callbacks called from C code should be nothrow. At a minimum, the C code that calls the callback is not going to be expecting an exit via exception, and so may leave things in an indeterminate state. Just for completeness: In a recent discussion on IRC I learned that vendor specific attributes exist for C compilers to mark functions as ok to use with exceptions. -- Marco
Re: Pegged, a Parsing Expression Grammar (PEG) generator in D
On Sunday, 11 March 2012 at 12:40:34 UTC, Alex Rønne Petersen wrote: Question: Are the generated parsers, AST nodes, etc classes or structs? Why is this important?
Re: A new blog article detailing the alternative function syntax
s/quiet easily/quite easily/g Nice article. I wish C++ had UFCS... On 8 August 2013 20:40, Jesse Phillips jesse.k.phillip...@gmail.com wrote: On Thursday, 8 August 2013 at 18:53:47 UTC, Gary Willoughby wrote: I've just finished a new blog article on the subject of alternative function syntax in D. I guess this is pretty straightforward stuff to all the people here but was a major source of confusion to me (and others?) when first learning D. I personally think this is more confusing than many people think. Hopefully this will quickly arm a developer with knowledge to be able to read and understand most D code. Let me know if i've missed anything important. http://nomad.so/2013/08/**alternative-function-syntax-**in-d/http://nomad.so/2013/08/alternative-function-syntax-in-d/ I'll post to reddit in the morning. The second non-member function example is part of the -property controversy. foo = 123; // called as foo(123) Not sure if you'd want that mentioned. -- -=Miles Stoudenmire=- miles.stoudenm...@gmail.com estou...@uci.edu http://itensor.org/miles/
DLang MongoDB Drive ??
d to make MongoDB database connection data extraction, data, how do I do want to add friends would appreciate if you help me in this regard.
std.json parsing real numbers.
I just check std.json for parsing real numbers.
import std.json;
import std.stdio: writeln;
int main()
{
auto json = parseJSON(1.24E +1);
writeln(toJSON(json));
return 0;
}
and
output: 12.4
It's bug or normal ?
Re: DLang MongoDB Drive ??
On Thursday, 8 August 2013 at 06:53:12 UTC, Batuhan Göksu wrote: d to make MongoDB database connection data extraction, data, how do I do want to add friends would appreciate if you help me in this regard. Check if you can use the driver from vibe.d project, if it's not possible, you can always import and use the C MongoDB library directly
Re: DLang MongoDB Drive ??
thanks but how can I solve using vibe.d I do not want to use your own server that hosts the very mass of a framework vibe.d How do I use the driver for MongoDB So the c
Re: std.json parsing real numbers.
On Thursday, 8 August 2013 at 08:04:49 UTC, khurshid wrote:
I just check std.json for parsing real numbers.
import std.json;
import std.stdio: writeln;
int main()
{
auto json = parseJSON(1.24E +1);
writeln(toJSON(json));
return 0;
}
and
output: 12.4
It's bug or normal ?
Yep, because 1.24E+1 is 12.4E0
Re: database applications
On Wednesday, 7 August 2013 at 21:41:30 UTC, John Joyus wrote: On 08/06/2013 04:55 PM, Carlos wrote: It is called GtkD. Are there any applications written with GtkD for Windows? Just want to look at the screen shots. Thanks. http://deoma-cmd.ru/en/SiteCreator.aspx biggest what i see
Re: std.json parsing real numbers.
On Thursday, 8 August 2013 at 10:11:07 UTC, MrSmith wrote:
On Thursday, 8 August 2013 at 08:04:49 UTC, khurshid wrote:
I just check std.json for parsing real numbers.
import std.json;
import std.stdio: writeln;
int main()
{
auto json = parseJSON(1.24E +1);
writeln(toJSON(json));
return 0;
}
and
output: 12.4
It's bug or normal ?
Yep, because 1.24E+1 is 12.4E0
I wrote not a 1.24E+1, a 1 .24E +1 with leading
spaces.
Re: std.array string.split() bug
On Wednesday, 7 August 2013 at 19:10:11 UTC, Borislav Kosharov
wrote:
Something strange happens when I do this:
unittest {
import std.array, std.string;
string s = test;
//assert(s.toUpper.split().join(-) == T-E-S-T);
//Memory allocation failed
//[Finished in 26.5s]
//CPU: 1% - 50% | 2.7GHz dual core
//RAM: 1.6GB - 2.6GB | 1GB diff
assert(s.split() == [t,e,s,t]);
//ditto
}
I just want to achieve what the commented assert's result
should be. Is there a better way to do that? And if it is
really a bug where should I report it?
There is probably a better way to do it, but I'm still mostly
ignorant about D.
auto test = test.map!(a=to!(string)(a)).join(-);
I would like to be able to write `test.join('-')` to get the
same result, after all one wants to intercalate a [repetition of]
char into an array of chars, but that does not currently work.
Re: DLang MongoDB Drive ??
On Thursday, 8 August 2013 at 10:05:14 UTC, Batuhan Göksu wrote: thanks but how can I solve using vibe.d I do not want to use your own server that hosts the very mass of a framework vibe.d How do I use the driver for MongoDB So the c It's not clear what you are asking, probably because of a language barrier. What languages are you fluent in?
Re: ctRegex! vs regex error
On Wednesday, 7 August 2013 at 22:36:39 UTC, Milvakili wrote:
Hi,
I can compile
void main(){
auto myRegx = regex(`(?!test)`);
}
however can not compile this one
void main(){
auto myRegx = ctRegex!(`(?!test)`);
}
code sample:http://dpaste.dzfl.pl/d38926f4
and get the following error:
...
std.regex.ctRegex!((?!test)) error instantiating
Sorry I really can't help you.
Except to let you know your code sample link is broken.
parseJSON bug
std.json parseJSON has a bug, // leading whitespaces auto json = parseJSON(1 .000); -- should throws, but it's success parsed as `1.000` . Khurshid...
Re: parseJSON bug
On Thursday, 8 August 2013 at 12:08:00 UTC, khurshid wrote:
std.json parseJSON has a bug,
// leading whitespaces
auto json = parseJSON(1
.000);
-- should throws, but it's success parsed as `1.000` .
Khurshid...
Or more...
auto json = parseJSON(`{ one: 1.24E +1
}`);//should throws.
writeln(toJSON(json)); // printed `{one:12.4}`
Re: parseJSON bug
On Thursday, 8 August 2013 at 12:08:00 UTC, khurshid wrote: std.json parseJSON has a bug, // leading whitespaces auto json = parseJSON(1 .000); -- should throws, but it's success parsed as `1.000` . Khurshid... I think bug reports should be here http://forum.dlang.org/group/digitalmars.D.bugs
Re: parseJSON bug
Am 08.08.2013 14:15, schrieb khurshid:
On Thursday, 8 August 2013 at 12:08:00 UTC, khurshid wrote:
std.json parseJSON has a bug,
// leading whitespaces
auto json = parseJSON(1 .000);
-- should throws, but it's success parsed as `1.000` .
Khurshid...
Or more...
auto json = parseJSON(`{ one: 1.24E +1
}`);//should throws.
writeln(toJSON(json)); // printed `{one:12.4}`
Why is this a bug? JSON ignores whitespaces outside strings.
Re: parseJSON bug
On Thursday, 8 August 2013 at 12:08:00 UTC, khurshid wrote: std.json parseJSON has a bug, // leading whitespaces auto json = parseJSON(1 .000); -- should throws, but it's success parsed as `1.000` . Khurshid... I don't think this is a bug, the json spec seems to indicate that this is valid.
Re: parseJSON bug
Tofu Ninja: I don't think this is a bug, the json spec seems to indicate that this is valid. The JSON decode of the Python2.6.6 standard library seems to refuse it: import json json.loads(1.000) 1.0 json.loads(1 .000) Traceback (most recent call last): File stdin, line 1, in module File ...\Python26\lib\json\__init__.py, line 307, in loads return _default_decoder.decode(s) File ...\Python26\lib\json\decoder.py, line 322, in decode raise ValueError(errmsg(Extra data, s, end, len(s))) ValueError: Extra data: line 1 column 35 - line 1 column 39 (char 35 - 39) Bye, bearophile
Re: parseJSON bug
On Thursday, 8 August 2013 at 12:38:39 UTC, SteveGuo wrote: I think bug reports should be here http://forum.dlang.org/group/digitalmars.D.bugs Actually, that only shows the activity on the bug tracker. New issues should be reported here: http://d.puremagic.com/issues
Re: parseJSON bug
On Thursday, 8 August 2013 at 12:38:39 UTC, SteveGuo wrote: On Thursday, 8 August 2013 at 12:08:00 UTC, khurshid wrote: std.json parseJSON has a bug, // leading whitespaces auto json = parseJSON(1 .000); -- should throws, but it's success parsed as `1.000` . Khurshid... I think bug reports should be here http://forum.dlang.org/group/digitalmars.D.bugs I reported. http://d.puremagic.com/issues/show_bug.cgi?id=10776
Re: parseJSON bug
Am 08.08.2013 14:54, schrieb bearophile: Tofu Ninja: I don't think this is a bug, the json spec seems to indicate that this is valid. The JSON decode of the Python2.6.6 standard library seems to refuse it: import json json.loads(1.000) 1.0 json.loads(1 .000) Traceback (most recent call last): File stdin, line 1, in module File ...\Python26\lib\json\__init__.py, line 307, in loads return _default_decoder.decode(s) File ...\Python26\lib\json\decoder.py, line 322, in decode raise ValueError(errmsg(Extra data, s, end, len(s))) ValueError: Extra data: line 1 column 35 - line 1 column 39 (char 35 - 39) Bye, bearophile JSON.parse(1 .000) SyntaxError: Unexpected token . If we follow an existing implementation, we should follow JavaScript
Re: parseJSON bug
David: If we follow an existing implementation, we should follow JavaScript In my opinion we should follow the formal JSON grammar. Bye, bearophile
Re: parseJSON bug
On Thursday, 8 August 2013 at 13:49:22 UTC, bearophile wrote: In my opinion we should follow the formal JSON grammar. This. Anyone who wants JavaScript behavior can use own third-party library bust standard library must behave according to published standards and specifications.
Re: parseJSON bug
On Thu, Aug 08, 2013 at 03:49:15PM +0200, bearophile wrote: David: If we follow an existing implementation, we should follow JavaScript In my opinion we should follow the formal JSON grammar. [...] +1. T -- Recently, our IT department hired a bug-fix engineer. He used to work for Volkswagen.
Re: Future of string lambda functions/string predicate functions
On Tue, Aug 06, 2013 at 11:05:56AM +0200, Jakob Ovrum wrote:
In Phobos pull request #1453 (Implement chunkBy.)[1], the topic of
string lambda functions has again cropped up. I think we should
clearly decide on some things regarding them. Questions such as; are
they a worthwhile alternative in the present language? Should they
be deprecated? Should they be supported in new additions to Phobos?
Some background: string lambda functions are a feature of
std.functional/std.range/std.algorithm, where strings can be passed
in lieu of functions as template alias arguments to various public
functions in these modules. The string becomes the return expression
of an anonymous function which implicitly has one or two arguments,
named a and b, like the string a 3 in the following example
expression:
arr.filter!a 3
When this feature was developed, there were no lambda function
literals in the language. There were anonymous functions, but their
syntactical overhead means they fare poorly as a replacement for
lambda functions:
arr.filter!((a) { return a 3; })
The effect is particularly jarring in bigger compositions:
assert([ 1, 2, 3, 4, 5 ].filter!((a) { return a 3; }).equal([1,
2]));
Since then, a first-class lambda syntax has been introduced, with
significantly less syntactic overhead:
arr.filter!(a = a 3)
The issue is then: is the old string lambda syntax obsolete in the
face of the new lambda literals?
[...]
Seems this thread has quietened down. So, what is the conclusion? Seems
like almost everyone concedes that silent deprecation is the way to go.
We still support string lambdas in the background, but in public docs we
promote the use of the new lambda syntax. Would that be a fair
assessment of this discussion?
What about new Phobos functions? Should we continue to support string
lambdas in new code?
T
--
Life is unfair. Ask too much from it, and it may decide you don't deserve what
you have now either.
Re: parseJSON bug
On Thursday, 8 August 2013 at 13:56:15 UTC, Dicebot wrote: On Thursday, 8 August 2013 at 13:49:22 UTC, bearophile wrote: In my opinion we should follow the formal JSON grammar. This. Anyone who wants JavaScript behavior can use own third-party library bust standard library must behave according to published standards and specifications. Then my reading says this really _is_ a bug. At least, according to http://www.ietf.org/rfc/rfc4627.txt, which states and shows only that: Insignificant whitespace is allowed before or after any of the six structural characters. ..unless there's a different version that supersedes that one? -Wyatt
Re: parseJSON bug
On Thursday, 8 August 2013 at 13:56:15 UTC, Dicebot wrote: On Thursday, 8 August 2013 at 13:49:22 UTC, bearophile wrote: In my opinion we should follow the formal JSON grammar. This. Anyone who wants JavaScript behavior can use own third-party library bust standard library must behave according to published standards and specifications. Exactly. Here's the official web page complete with nice graphics detailing the grammar: http://json.org/. I've read the JSON RFC before, but I can't remember what it says about whitespace within a basic value, but the graphics here make it very clear that whitespace does *not* belong inside a value. The real question is, is this worth fixing before std.serialize makes it in? There will likely be other bugs once/if that's accepted. I tried extending std.json in the past with static reflection, but that didn't make it in for this very reason.
Re: std.array string.split() bug
On Wednesday, 7 August 2013 at 19:10:11 UTC, Borislav Kosharov
wrote:
Something strange happens when I do this:
unittest {
import std.array, std.string;
string s = test;
//assert(s.toUpper.split().join(-) == T-E-S-T);
//Memory allocation failed
//[Finished in 26.5s]
//CPU: 1% - 50% | 2.7GHz dual core
//RAM: 1.6GB - 2.6GB | 1GB diff
assert(s.split() == [t,e,s,t]);
//ditto
}
I just want to achieve what the commented assert's result
should be. Is there a better way to do that? And if it is
really a bug where should I report it?
Bugs go here: http://d.puremagic.com/issues/
Re: std.json parsing real numbers.
On Thursday, 8 August 2013 at 08:04:49 UTC, khurshid wrote:
I just check std.json for parsing real numbers.
import std.json;
import std.stdio: writeln;
int main()
{
auto json = parseJSON(1.24E +1);
writeln(toJSON(json));
return 0;
}
and
output: 12.4
It's bug or normal ?
As mentioned in a different thread, it's a bug since it doesn't
adhere to the JSON standard.
Re: ctRegex! vs regex error
On Wednesday, 7 August 2013 at 22:36:39 UTC, Milvakili wrote:
Hi,
I can compile
void main(){
auto myRegx = regex(`(?!test)`);
}
however can not compile this one
void main(){
auto myRegx = ctRegex!(`(?!test)`);
}
code sample:http://dpaste.dzfl.pl/d38926f4
and get the following error:
snip...
Go ahead and add it to the issue tracker:
http://d.puremagic.com/issues/
FWIW, I get the same error, and I get a similar one in LDC:
/usr/include/d/std-ldc/std/regex.d(4350): Error: ['N', 'e', 'g',
'l', 'o', 'o', 'k', 'a', 'h', 'e', 'a', 'd', 'S', 't', 'a', 'r',
't'][0LU..17LU]
/usr/include/d/std-ldc/std/regex.d(4308):called from
here: this.ctGenGroup(ir, result.addr)
/usr/include/d/std-ldc/std/regex.d(4746):called from
here: this.ctGenBlock(re.ir, 0)
/usr/include/d/std-ldc/std/regex.d(4795):called from
here: context.ctGenRegEx(re)
/usr/include/d/std-ldc/std/regex.d(6482):called from
here: ctGenRegExCode(regex((?!test), []))
/usr/include/d/std-ldc/std/regex.d(6506): Error: template
instance std.regex.ctRegexImpl!((?!test), []) error
instantiating
instantiatied in test.d(10): ctRegex!((?!test))
test.d(10): Error: template instance
std.regex.ctRegex!((?!test)) error instantiating
Re: parseJSON bug
On Thursday, 8 August 2013 at 13:56:15 UTC, Dicebot wrote: On Thursday, 8 August 2013 at 13:49:22 UTC, bearophile wrote: In my opinion we should follow the formal JSON grammar. This. Anyone who wants JavaScript behavior can use own third-party library bust standard library must behave according to published standards and specifications. A formal grammar can be found here starting on page 202 but I don't know enough about grammars to be able to interpret it. http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf Im starting to become less sure if its a bug or not...
Re: parseJSON bug
The real question is, is this worth fixing before std.serialize makes it in? There will likely be other bugs once/if that's accepted. I tried extending std.json in the past with static reflection, but that didn't make it in for this very reason. Yep no one seems to care about std.json.
Re: std.json parsing real numbers.
On Thursday, 8 August 2013 at 10:13:51 UTC, khurshid wrote:
On Thursday, 8 August 2013 at 10:11:07 UTC, MrSmith wrote:
On Thursday, 8 August 2013 at 08:04:49 UTC, khurshid wrote:
I just check std.json for parsing real numbers.
import std.json;
import std.stdio: writeln;
int main()
{
auto json = parseJSON(1.24E +1);
writeln(toJSON(json));
return 0;
}
and
output: 12.4
It's bug or normal ?
Yep, because 1.24E+1 is 12.4E0
I wrote not a 1.24E+1, a 1 .24E +1 with leading
spaces.
Well what should it be if it's not 12.4? If you think it should
be 2.24 you are wrong. In JSON there are no additions or
subtractions. It is only static data. It is just a format. And
although JSON stands for JavaScriptObjectNotation it isn't JS.
Even if {key:1.24 + 1} is valid JS it is not valid JSON.
Re: parseJSON bug
On Thursday, 8 August 2013 at 13:56:15 UTC, Dicebot wrote: On Thursday, 8 August 2013 at 13:49:22 UTC, bearophile wrote: In my opinion we should follow the formal JSON grammar. This. Anyone who wants JavaScript behavior can use own third-party library bust standard library must behave according to published standards and specifications. I agree with Dicebot. I posted on the other thread for JSON real numbers and explained why it isn't a bug.
Re: DLang MongoDB Drive ??
Thank you friends, for now postponed the event MongoDB.
Re: ctRegex! vs regex error
08-Aug-2013 02:36, Milvakili пишет:
Hi,
I can compile
void main(){
auto myRegx = regex(`(?!test)`);
}
however can not compile this one
void main(){
auto myRegx = ctRegex!(`(?!test)`);
}
Well, it should have said sorry, unsupported yet or something to that
extent. It's a bug regardless as it shouldn't spit this much of garbage
on the screen.
ctRegex is not yet up to the full feature set of the run-time one. The
prime things missing are exactly zero-width assertions
(look-ahead/look-behind). And certain things will simply make compiler
explode...
Reasons for not supporting it yet are various but the primary one is
that I can't even fully test the current subset yet (!) due to the sorry
state of CTFE (still!). Things definitely greatly improved since then
but don't get your hopes high it's not something to fix overnight.
--
Dmitry Olshansky
Re: DLang MongoDB Drive ??
On Thu, 08 Aug 2013 12:05:10 +0200 Batuhan Göksu batuhango...@gmail.com wrote: thanks but how can I solve using vibe.d I do not want to use your own server that hosts the very mass of a framework vibe.d How do I use the driver for MongoDB So the c You don't need to use all of vibe.d. Vibe.d is very modular, you can use just the parts that you need.
Re: parseJSON bug
On Thu, 08 Aug 2013 17:17:38 +0200 Tofu Ninja emmo...@purdue.edu wrote: On Thursday, 8 August 2013 at 13:56:15 UTC, Dicebot wrote: On Thursday, 8 August 2013 at 13:49:22 UTC, bearophile wrote: In my opinion we should follow the formal JSON grammar. This. Anyone who wants JavaScript behavior can use own third-party library bust standard library must behave according to published standards and specifications. A formal grammar can be found here starting on page 202 but I don't know enough about grammars to be able to interpret it. http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf Im starting to become less sure if its a bug or not... I think that makes it clear that whitespace is NOT allowed within numeric or fractional literals. Note that the JSONNumber and JSONFraction tokens are defined in the lexical section (15.12.1.1). In a lexer, whitespace is something that is always handled explicitly (as they do, in both the JSONWhiteSpace and JSONStringCharacter tokens). Down in the Syntactic Grammar section (15.12.1.2), they don't explicitly mention anything about whitespace (for example, in the JSONElementList token, where we already *know* whitespace is allowed). This is undoubtedly because (aside from lexing) whitespace is generally NOT explicit, but rather implied to optionally exist before/after each token. It sounds like the bug is that std.json is currently treating JSONNumber (and maybe JSONFraction too) as a parser-handled nonterminal, instead of a lexer-handled terminal as the spec indicates.
Re: parseJSON bug
On Thursday, 8 August 2013 at 15:17:40 UTC, Tofu Ninja wrote: A formal grammar can be found here starting on page 202 but I don't know enough about grammars to be able to interpret it. http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf Im starting to become less sure if its a bug or not... I don't recogise that exact BNF notation (single colon? New to me.), but unless it's fairly...unique, it's still a bug according to a strict reading. (I feel the RFC version is somewhat more clear, honestly.) -Wyatt
Re: std.json parsing real numbers.
On Thu, 08 Aug 2013 17:20:16 +0200
Borislav Kosharov bo...@gmail.com wrote:
On Thursday, 8 August 2013 at 10:13:51 UTC, khurshid wrote:
On Thursday, 8 August 2013 at 10:11:07 UTC, MrSmith wrote:
On Thursday, 8 August 2013 at 08:04:49 UTC, khurshid wrote:
I just check std.json for parsing real numbers.
import std.json;
import std.stdio: writeln;
int main()
{
auto json = parseJSON(1.24E +1);
writeln(toJSON(json));
return 0;
}
and
output: 12.4
It's bug or normal ?
Yep, because 1.24E+1 is 12.4E0
I wrote not a 1.24E+1, a 1 .24E +1 with leading
spaces.
Well what should it be if it's not 12.4?
A syntax error.
Re: parseJSON bug
On Thursday, August 08, 2013 14:38:34 SteveGuo wrote: I think bug reports should be here http://forum.dlang.org/group/digitalmars.D.bugs Please, never, never post to that list. It shouldn't even accept posts to it (and it may not anymore, since I haven't seen anyone post to it for a while). The whole purpose of that list is to sign up for notifications from bugzilla, and bugzilla will post to the list whenever a bug report is created or changed. All bug reports should go to http://d.puremagic.com/issues - Jonathan M Davis
Re: parseJSON bug
On Thu, Aug 08, 2013 at 11:45:19AM -0400, Nick Sabalausky wrote:
On Thu, 08 Aug 2013 17:17:38 +0200
Tofu Ninja emmo...@purdue.edu wrote:
On Thursday, 8 August 2013 at 13:56:15 UTC, Dicebot wrote:
On Thursday, 8 August 2013 at 13:49:22 UTC, bearophile wrote:
In my opinion we should follow the formal JSON grammar.
This. Anyone who wants JavaScript behavior can use own
third-party library bust standard library must behave according
to published standards and specifications.
A formal grammar can be found here starting on page 202 but I
don't know enough about grammars to be able to interpret it.
http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf
Im starting to become less sure if its a bug or not...
[...]
I find that the spec is not very clear as to what is/isn't allowed.
RFC-4627 is more unambiguous: it explicitly states that insignificant
whitespace is allowed before or after any of the six structural
characters, which are defined (in section 2) to be:
[ { ] } : ,
Section 2.4 in RFC-4627 defines the number format very clearly. There is
no mention of insignificant whitespace. This, plus the statement above
in section 2 about structural characters, makes it clear that whitespace
is NOT allowed inside a number literal.
So please file a bug against std.json.
T
--
If you compete with slaves, you become a slave. -- Norbert Wiener
Re: parseJSON bug
On Thursday, 8 August 2013 at 15:15:44 UTC, David wrote: The real question is, is this worth fixing before std.serialize makes it in? There will likely be other bugs once/if that's accepted. I tried extending std.json in the past with static reflection, but that didn't make it in for this very reason. Yep no one seems to care about std.json. I heard about std.xml being crap and was going to use std.json, then I ran into this thread. So what should one use to parse json, or xml for that matter?
Re: std.json parsing real numbers.
On Thu, Aug 08, 2013 at 05:20:16PM +0200, Borislav Kosharov wrote:
On Thursday, 8 August 2013 at 10:13:51 UTC, khurshid wrote:
On Thursday, 8 August 2013 at 10:11:07 UTC, MrSmith wrote:
On Thursday, 8 August 2013 at 08:04:49 UTC, khurshid wrote:
I just check std.json for parsing real numbers.
import std.json;
import std.stdio: writeln;
int main()
{
auto json = parseJSON(1.24E +1);
writeln(toJSON(json));
return 0;
}
and
output: 12.4
It's bug or normal ?
Yep, because 1.24E+1 is 12.4E0
I wrote not a 1.24E+1, a 1 .24E +1 with leading
spaces.
Well what should it be if it's not 12.4? If you think it should be
2.24 you are wrong.
If you think it should be 12.4, you're wrong too. This is illegal syntax
according to the JSON spec and RFC 4627 (see sections 2 and 2.4:
whitespace is not allowed inside a number literal). It should throw an
exception, not return any value.
T
--
IBM = I Blame Microsoft
Re: Future of string lambda functions/string predicate functions
On Thursday, August 08, 2013 07:29:56 H. S. Teoh wrote: Seems this thread has quietened down. So, what is the conclusion? Seems like almost everyone concedes that silent deprecation is the way to go. We still support string lambdas in the background, but in public docs we promote the use of the new lambda syntax. Would that be a fair assessment of this discussion? I find it interesting that very few Phobos devs have weighed in on the matter, but unfortunately, most of the posters who have weighed in do seem to be against keeping them. What about new Phobos functions? Should we continue to support string lambdas in new code? Personally, I don't think that silent deprecation is ever a good idea. If we do that, we're going to end up with confusion over which functions accept strings and which don't, and it won't be clear that we're trying to get rid of them. I think that we need to clearly choose one path or the other: either 1. Choose to keep string lambdas around permanently and support them, even if they're used for a limited number of use cases (e.g. with simple lambdas which use operators but not function calls). or 2. Put them on the path to deprecation towards removal (in which case, they might actually stay marked as deprecated for quite some time to come but would clearly be unacceptable for new code and might be fully removed at some point in the future). - Jonathan M Davis
Re: DLang MongoDB Drive ??
On 08/08/2013 03:49 AM, John Colvin wrote: On Thursday, 8 August 2013 at 10:05:14 UTC, Batuhan Göksu wrote: What languages are you fluent in? Batuhan Göksu is a Turkish name! :) Batuhan, the Turkish D community is at http://ddili.org/forum Ali
Re: Future of string lambda functions/string predicate functions
On Thu, Aug 08, 2013 at 09:52:05AM -0700, Jonathan M Davis wrote: On Thursday, August 08, 2013 07:29:56 H. S. Teoh wrote: Seems this thread has quietened down. So, what is the conclusion? Seems like almost everyone concedes that silent deprecation is the way to go. We still support string lambdas in the background, but in public docs we promote the use of the new lambda syntax. Would that be a fair assessment of this discussion? I find it interesting that very few Phobos devs have weighed in on the matter, but unfortunately, most of the posters who have weighed in do seem to be against keeping them. [...] Well, it would be nice of the rest of the Phobos devs speak up, otherwise they are giving the wrong impression about the state of things. T -- Many open minds should be closed for repairs. -- K5 user
std.algorithm unittest OOM package.d
After the latest Phobos update, I can't run the Phobos unittests anymore; std.algorithm runs out of memory. What do you guys think? Since we have package.d support now, I think it's about time we split std.algorithm up into smaller pieces. As a first stab at it, we could split it up according to the categories already outlined in the docs: searching, comparison, iteration, sorting, set operations, mutation. So we'd have something like: phobos/ phobos/std/ phobos/std/algorithm phobos/std/algorithm/package.d phobos/std/algorithm/search.d phobos/std/algorithm/cmp.d phobos/std/algorithm/iter.d phobos/std/algorithm/sort.d phobos/std/algorithm/set.d phobos/std/algorithm/mutation.d (Yes I know some of you are going to complain about the naming -- the names are not important, we can squabble over that later; what's important is that it's time to dissect that monster called std.algorithm.) In addition to alleviating OOM problems, we'd also alleviate compiler memory usage issues when compiling std.algorithm. As well as code maintainability issues (std.algorithm is just too unwieldy right now, to the point I tend to write new algorithm additions in a completely separate project until it's well-tested and ready, before I put it into std.algorithm for integration testing; it's just too painful to have to recompile the entire std.algorithm every single code iteration). As well as allowing multithreaded unittest runs (this may help the autotesters do their thing faster?). T -- Dogs have owners ... cats have staff. -- Krista Casada
UFCS for templates
Can we have UFCS for templates?
e.g.,
T New(T, A...)(A args) { }
T t = T.New(args);
Note, in this case, the type parameter is substituted.
Re: parseJSON bug
Am 08.08.2013 18:26, schrieb Lemonfiend: On Thursday, 8 August 2013 at 15:15:44 UTC, David wrote: The real question is, is this worth fixing before std.serialize makes it in? There will likely be other bugs once/if that's accepted. I tried extending std.json in the past with static reflection, but that didn't make it in for this very reason. Yep no one seems to care about std.json. I heard about std.xml being crap and was going to use std.json, then I ran into this thread. So what should one use to parse json, or xml for that matter? std.json is Ok, the API is a real pain. I made a pull request improving the API a few weeks ago, no one seems to really care. Better use a 3rd party implementation or roll your own (what seems to be Ds mentallity)
Re: parseJSON bug
On Thursday, 8 August 2013 at 15:45:22 UTC, Nick Sabalausky wrote: On Thu, 08 Aug 2013 17:17:38 +0200 Tofu Ninja emmo...@purdue.edu wrote: On Thursday, 8 August 2013 at 13:56:15 UTC, Dicebot wrote: On Thursday, 8 August 2013 at 13:49:22 UTC, bearophile wrote: In my opinion we should follow the formal JSON grammar. This. Anyone who wants JavaScript behavior can use own third-party library bust standard library must behave according to published standards and specifications. A formal grammar can be found here starting on page 202 but I don't know enough about grammars to be able to interpret it. http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf Im starting to become less sure if its a bug or not... I think that makes it clear that whitespace is NOT allowed within numeric or fractional literals. Note that the JSONNumber and JSONFraction tokens are defined in the lexical section (15.12.1.1). In a lexer, whitespace is something that is always handled explicitly (as they do, in both the JSONWhiteSpace and JSONStringCharacter tokens). Down in the Syntactic Grammar section (15.12.1.2), they don't explicitly mention anything about whitespace (for example, in the JSONElementList token, where we already *know* whitespace is allowed). This is undoubtedly because (aside from lexing) whitespace is generally NOT explicit, but rather implied to optionally exist before/after each token. It sounds like the bug is that std.json is currently treating JSONNumber (and maybe JSONFraction too) as a parser-handled nonterminal, instead of a lexer-handled terminal as the spec indicates. Just out of curiosity what is this sort of grammar format called or what would one want to try to look up to understand it? I just have seen it around a few times and never really knew what it was about other than some how it describes a language.
Re: UFCS for templates
On Thursday, 8 August 2013 at 17:35:02 UTC, JS wrote:
Can we have UFCS for templates?
e.g.,
T New(T, A...)(A args) { }
T t = T.New(args);
Note, in this case, the type parameter is substituted.
That would be nice things to have, it would allow the
parse!type(...) to be turned into type.parse(...) which is the C#
way of doing it
Im just not sure if there would ever be a time where this might
cause ambiguity, like where it was not obvious if the thing
before the '.' should be the first type in the template or the
first argument in the function.
Re: UFCS for templates
On Thursday, 8 August 2013 at 17:35:02 UTC, JS wrote:
Can we have UFCS for templates?
e.g.,
T New(T, A...)(A args) { }
T t = T.New(args);
Note, in this case, the type parameter is substituted.
As always, providing motivating use case and advantage/cost
comparison is usual requirement to make something happen.
DIP's exist for a reason.
Re: UFCS for templates
On Thursday, August 08, 2013 19:35:01 JS wrote:
Can we have UFCS for templates?
e.g.,
T New(T, A...)(A args) { }
T t = T.New(args);
Note, in this case, the type parameter is substituted.
And how is the compiler supposed to know whether T is being passed as a
template argument or a function argument? In some cases, it'll be clear. In
others (such as with alias parameters), the compiler will have no way of
knowing.
Also, I think that allowing it would increase confusion for little benefit
anyway. The primary benefit of UFCS is making it so that generic code can call
functions without caring about whether they're member functions or free
functions. There is no such benefit with template arguments.
- Jonathan M Davis
Re: parseJSON bug
On Thursday, 8 August 2013 at 17:37:37 UTC, Tofu Ninja wrote: Just out of curiosity what is this sort of grammar format called or what would one want to try to look up to understand it? I just have seen it around a few times and never really knew what it was about other than some how it describes a language. That'd be some flavour of BNF: https://en.wikipedia.org/wiki/Backus%E2%80%93Naur_form Very handy thing to know how to read (though I prefer PEGs). -Wyatt
Re: parseJSON bug
On Thursday, 8 August 2013 at 17:33:38 UTC, David wrote: I made a pull request improving the API a few weeks ago, no one seems to really care. Phobos needs a new dictator.
Re: parseJSON bug
On Thu, Aug 08, 2013 at 08:24:19PM +0200, Adam D. Ruppe wrote: On Thursday, 8 August 2013 at 17:33:38 UTC, David wrote: I made a pull request improving the API a few weeks ago, no one seems to really care. Phobos needs a new dictator. Or rather, Phobos needs more reviewers/committers. In the past 2 weeks or so, pull requests have been piling up, and lots of them have a green on the autotester, yet very few requests are actually being pulled. Sounds like the usually-active Phobos devs are busy with other things. T -- In a world without fences, who needs Windows and Gates? -- Christian Surchi
Re: parseJSON bug
Am 08.08.2013 20:24, schrieb Adam D. Ruppe: On Thursday, 8 August 2013 at 17:33:38 UTC, David wrote: I made a pull request improving the API a few weeks ago, no one seems to really care. Phobos needs a new dictator. Either that, or I will soon start my own standard lib and stop caring about phobos. I think, I even know a few who would help me...
Re: std.json parsing real numbers.
On Thursday, 8 August 2013 at 16:05:56 UTC, Nick Sabalausky wrote:
On Thu, 08 Aug 2013 17:20:16 +0200
Borislav Kosharov bo...@gmail.com wrote:
On Thursday, 8 August 2013 at 10:13:51 UTC, khurshid wrote:
On Thursday, 8 August 2013 at 10:11:07 UTC, MrSmith wrote:
On Thursday, 8 August 2013 at 08:04:49 UTC, khurshid wrote:
I just check std.json for parsing real numbers.
import std.json;
import std.stdio: writeln;
int main()
{
auto json = parseJSON(1.24E +1);
writeln(toJSON(json));
return 0;
}
and
output: 12.4
It's bug or normal ?
Yep, because 1.24E+1 is 12.4E0
I wrote not a 1.24E+1, a 1 .24E +1 with leading
spaces.
Well what should it be if it's not 12.4?
A syntax error.
I don't think this would cause any problems. It would just throw
syntax error because there is white-space between? It would be
just annoying to get syntax error because of extra white-space.
Maybe this is one of the situations where we should think It's
not a bug, it's a feature!
Unless there is a situation that would make no sense to work or
something, it should be left like it is now.
Re: std.json parsing real numbers.
On Thu, Aug 08, 2013 at 08:46:15PM +0200, Borislav Kosharov wrote:
On Thursday, 8 August 2013 at 16:05:56 UTC, Nick Sabalausky wrote:
On Thu, 08 Aug 2013 17:20:16 +0200
Borislav Kosharov bo...@gmail.com wrote:
On Thursday, 8 August 2013 at 10:13:51 UTC, khurshid wrote:
On Thursday, 8 August 2013 at 10:11:07 UTC, MrSmith wrote:
On Thursday, 8 August 2013 at 08:04:49 UTC, khurshid wrote:
I just check std.json for parsing real numbers.
import std.json;
import std.stdio: writeln;
int main()
{
auto json = parseJSON(1.24E +1);
writeln(toJSON(json));
return 0;
}
and
output: 12.4
It's bug or normal ?
Yep, because 1.24E+1 is 12.4E0
I wrote not a 1.24E+1, a 1 .24E +1 with leading
spaces.
Well what should it be if it's not 12.4?
A syntax error.
I don't think this would cause any problems. It would just throw
syntax error because there is white-space between? It would be just
annoying to get syntax error because of extra white-space.
Maybe this is one of the situations where we should think It's not
a bug, it's a feature!
Unless there is a situation that would make no sense to work or
something, it should be left like it is now.
This makes std.json non-conformant to the JSON spec. What if the extra
white-space is an indication of data corruption? We should not blindly
accept it just because we can.
T
--
Life is all a great joke, but only the brave ever get the point. -- Kenneth
Rexroth
Re: std.json parsing real numbers.
On Thursday, 8 August 2013 at 18:46:17 UTC, Borislav Kosharov
wrote:
On Thursday, 8 August 2013 at 16:05:56 UTC, Nick Sabalausky
wrote:
On Thu, 08 Aug 2013 17:20:16 +0200
Borislav Kosharov bo...@gmail.com wrote:
On Thursday, 8 August 2013 at 10:13:51 UTC, khurshid wrote:
On Thursday, 8 August 2013 at 10:11:07 UTC, MrSmith wrote:
On Thursday, 8 August 2013 at 08:04:49 UTC, khurshid wrote:
I just check std.json for parsing real numbers.
import std.json;
import std.stdio: writeln;
int main()
{
auto json = parseJSON(1.24E +1);
writeln(toJSON(json));
return 0;
}
and
output: 12.4
It's bug or normal ?
Yep, because 1.24E+1 is 12.4E0
I wrote not a 1.24E+1, a 1 .24E +1 with
leading spaces.
Well what should it be if it's not 12.4?
A syntax error.
I don't think this would cause any problems. It would just
throw syntax error because there is white-space between? It
would be just annoying to get syntax error because of extra
white-space.
Maybe this is one of the situations where we should think It's
not a bug, it's a feature!
Unless there is a situation that would make no sense to work or
something, it should be left like it is now.
Its not really a situation where we should deviate from the
specs... it is starting to seem that the json specs say that
there should be no white spaces and as this is a standard lib, we
should conform to that
Re: parseJSON bug
On Thursday, 8 August 2013 at 18:31:52 UTC, David wrote: Am 08.08.2013 20:24, schrieb Adam D. Ruppe: On Thursday, 8 August 2013 at 17:33:38 UTC, David wrote: I made a pull request improving the API a few weeks ago, no one seems to really care. Phobos needs a new dictator. Either that, or I will soon start my own standard lib and stop caring about phobos. I think, I even know a few who would help me... Maybe the Tango developers would want to join in :o)
Multiple alias for multiple functions?
I want to make a simple Vector struct class:
struct Vector {
alias _data this;
alias data!0 x, width;
alias data!1 y, height;
private:
@property float data(int i)() {
return _data[i];
}
@property void data(int i)(float value) {
_data[i] = value;
}
float[2] _data;
}
But I get two similar errors:
Vector.data matches more than one template declaration,
vector.d(9):data(int i)() and vector.d(13):data(int i)(float
value)
I see that it might cause problems to have ambiguous aliases, but
does anyone know how I might implement this? Should I remove the
struct and just make @property x for float[2] and the others?
Re: parseJSON bug
On Thursday, 8 August 2013 at 18:31:52 UTC, David wrote: Am 08.08.2013 20:24, schrieb Adam D. Ruppe: On Thursday, 8 August 2013 at 17:33:38 UTC, David wrote: I made a pull request improving the API a few weeks ago, no one seems to really care. Phobos needs a new dictator. Either that, or I will soon start my own standard lib and stop caring about phobos. I think, I even know a few who would help me... It is really bad that people are actually talking about starting there own standard lib, I wasn't around for the whole phobos vs tango thing but from what I hear, it wasn't pretty. If there is problems with phobos or the way its managed, I feel like we should try and fix them and not try to replace it.
Re: Multiple alias for multiple functions?
On Thursday, 8 August 2013 at 20:14:58 UTC, Borislav Kosharov
wrote:
I want to make a simple Vector struct class:
struct Vector {
alias _data this;
alias data!0 x, width;
alias data!1 y, height;
private:
@property float data(int i)() {
return _data[i];
}
@property void data(int i)(float value) {
_data[i] = value;
}
float[2] _data;
}
But I get two similar errors:
Vector.data matches more than one template declaration,
vector.d(9):data(int i)() and vector.d(13):data(int i)(float
value)
I see that it might cause problems to have ambiguous aliases,
but does anyone know how I might implement this? Should I
remove the struct and just make @property x for float[2] and
the others?
template data(int i) {
@property float data() {
return _data[i];
}
@property void data(float value) {
_data[i] = value;
}
}
Re: parseJSON bug
On Thu, Aug 08, 2013 at 10:15:28PM +0200, Tofu Ninja wrote: On Thursday, 8 August 2013 at 18:31:52 UTC, David wrote: Am 08.08.2013 20:24, schrieb Adam D. Ruppe: On Thursday, 8 August 2013 at 17:33:38 UTC, David wrote: I made a pull request improving the API a few weeks ago, no one seems to really care. Phobos needs a new dictator. Either that, or I will soon start my own standard lib and stop caring about phobos. I think, I even know a few who would help me... It is really bad that people are actually talking about starting there own standard lib, I wasn't around for the whole phobos vs tango thing but from what I hear, it wasn't pretty. If there is problems with phobos or the way its managed, I feel like we should try and fix them and not try to replace it. Yeah, another Phobos/Tango (or whatever it may be) split is probably going to be the thing that finally kills off D before it ever reaches widespread adoption. Please, let's not go there. Here's another approach. If you feel something is wrong with Phobos and your pulls aren't getting accepted for whatever reason, why not package it up nicely in a form that's easily installable by users, and publish it? Say you have a replacement for std.json that you feel is far superior, well, then make it installable as a standalone library (say alt.json), and promote it here and get many people to start to use it. Once it's widely-used, I suspect it will be far easier to convince people to put it into Phobos. :-) T -- I'm running Windows '98. Yes. My computer isn't working now. Yes, you already said that. -- User-Friendly
Re: parseJSON bug
Am 08.08.2013 22:15, schrieb Tofu Ninja: On Thursday, 8 August 2013 at 18:31:52 UTC, David wrote: Am 08.08.2013 20:24, schrieb Adam D. Ruppe: On Thursday, 8 August 2013 at 17:33:38 UTC, David wrote: I made a pull request improving the API a few weeks ago, no one seems to really care. Phobos needs a new dictator. Either that, or I will soon start my own standard lib and stop caring about phobos. I think, I even know a few who would help me... It is really bad that people are actually talking about starting there own standard lib, I wasn't around for the whole phobos vs tango thing but from what I hear, it wasn't pretty. If there is problems with phobos or the way its managed, I feel like we should try and fix them and not try to replace it. phobos is actually useable, still I don't like many of its design choices. I feel the same with D. D itself is better than most languages, I still think there is a long way to go, but official D people seem like it's enough and block progress (e.g. @property/-property the whole situation is a mess, but instead of properly reimplementing it, they try to fix an already broken system and break code with it, why not break code once, but replace it with a proper system)
Re: std.json parsing real numbers.
On 08/08/2013 11:46 AM, Borislav Kosharov wrote: I wrote not a 1.24E+1, a 1 .24E +1 with leading spaces. Well what should it be if it's not 12.4? A syntax error. I don't think this would cause any problems. It would just throw syntax error because there is white-space between? It would be just annoying to get syntax error because of extra white-space. Maybe this is one of the situations where we should think It's not a bug, it's a feature! Unless there is a situation that would make no sense to work or something, it should be left like it is now. How about integers? I wouldn't expect 4 2 to be parsed silently as 42. Ali
Re: parseJSON bug
On Thu, Aug 08, 2013 at 11:40:45PM +0200, David wrote: Am 08.08.2013 22:15, schrieb Tofu Ninja: [...] It is really bad that people are actually talking about starting there own standard lib, I wasn't around for the whole phobos vs tango thing but from what I hear, it wasn't pretty. If there is problems with phobos or the way its managed, I feel like we should try and fix them and not try to replace it. phobos is actually useable, still I don't like many of its design choices. I feel the same with D. D itself is better than most languages, I still think there is a long way to go, but official D people seem like it's enough and block progress Well, I don't speak for them, whoever they are, but in my understanding one of the main reasons there's such a high bar to changes is because we're trying to stabilize the language so that adopters can rely on it not having drastic changes every other release, that will require massive code rewrites. No language will ever be perfect, and if we keep on breaking people's existing code in the endless quest to improve the language, D will have no users left. (e.g. @property/-property the whole situation is a mess, but instead of properly reimplementing it, they try to fix an already broken system and break code with it, why not break code once, but replace it with a proper system) The problem is that nobody can agree on what the proper system should be. We've had that @property discussion before. Nobody is happy with the current state of affairs, but nobody can agree with what the solution should be, either. We just have long neverending debates about it but no conclusion is ever reached. Perhaps what's needed, is somebody who's headstrong enough, and persistent enough, to just pick one of the solutions -- any one of them -- take the time to implement it in DMD, and show it to the rest of us to prove how superior it is. Then continue to pester Walter ceaselessly until he agrees to merge it. In the current state of stalemate, an actual, working implementation of a solution (even if it's not quite the one that one may have in mind) should be pretty convincing. Complaining about it yet being unwilling to do anything about it, OTOH, is very likely to just fall on deaf ears, judging from what I've seen around these parts. That's just the way things work, unfortunately. *shrug* T -- Some days you win; most days you lose.
Re: parseJSON bug
Am Thu, 08 Aug 2013 22:15:28 +0200
schrieb Tofu Ninja emmo...@purdue.edu:
On Thursday, 8 August 2013 at 18:31:52 UTC, David wrote:
Am 08.08.2013 20:24, schrieb Adam D. Ruppe:
On Thursday, 8 August 2013 at 17:33:38 UTC, David wrote:
I made a pull request improving the API a few weeks ago,
no one seems to really care.
Phobos needs a new dictator.
Either that, or I will soon start my own standard lib and stop
caring
about phobos. I think, I even know a few who would help me...
It is really bad that people are actually talking about starting
there own standard lib, I wasn't around for the whole phobos vs
tango thing but from what I hear, it wasn't pretty. If there is
problems with phobos or the way its managed, I feel like we
should try and fix them and not try to replace it.
I'm sorry that you've had such bad experiences when contributing to
phobos. I think this is less of a phobos than a std.json problem. I'd
like to explain the special issue we have with std.json - as far as I
understand it:
std.json is a very old module:
* It's API is not up to current phobos standards
* there are some - probably serious - bugs
* no interaction with ranges
* doesn't use @safe const, nothrow IIRC
* inherently unsafe API (accessing the union part)
* could be (should be) much faster
* the orignal author is no longer around. AFAICS there's nobody feeling
responsible for this module.
The last point is probably the biggest problem. Most people here would
probably like to see a complete replacement - std.json2. Some of us
have argued that we should remove std.json (and std.xml) from phobos
ASAP even if there's no replacement as this code is really not what we
want in the standard lib.
Others are strongly against any API breakage (especially without
replacement) and therefore std.json is still there. But this makes
things even more difficult: Improving std.json means we'd have both API
breakage and a sub-optimal std.json. I guess nobody wants to merge
changes to std.json because 1) they feel std.json has to be replaced
anyway and improving the old design is wasting time 2) they don't want
to be blamed for any possible API breakage.
There were some discussions how a std.json replacement should look
like, I'll try to reiterate the main points:
=== Input API: ===
1) A pull-parser/tokenizer/lexer
* Should implement a InputRange API with ElementType JSONToken.
* Should be as fast as possible
* shouldn't allocate memory
* shouldn't even convert strings to numbers. Instead JSONToken
should have a 'type' field (ObjectStart, ArrayStart, String,
Number, ...) and a value field which is always a (raw!) w/d/string.
A templated T get!(JSONType) helper which could also verify the
type would be useful. Any decoding of JSON strings should be done
in the get function. Get may optionally use some caching.
* It should be specialized for input arrays
(const/immutable/mutable) of char/wchar/dchar which are completely
in-memory and use slicing in these cases.
* It should work with arbitrary ranges of w/d/char. To avoid memory
allocation a fixed-length internal buffer should be used and token
values should be slices to that buffer. (It would be good if the
user can query whether values are slices of the original input
which can be reused, or sliced of the iternal buffer which have to
be .dup ed to keep them)
2) A DOM-API
* Should be based on 1)
* Same principle as current std.json, but in modern D
* API similar to std.variant, DYAML
optional, nice-to have:
3) A Sax-style API (based on 1)
4) A simple deserialization API
* basically T fromJSON(T, CHAR)(CHAR input) (supporting all
inputs supported by 1)
* Shouldn't allocate any memory
* Optionally skipping fields which are in the JSON data but not part
of T and the other way round.
* Usage: auto artist = fromJSON(Artist, `{name: , songs:42}´);
=== Output API: ===
1) A OutputRange of JSONTokens
* Shouldn't allocate
* Should work on top of other OutputRanges
* should accept the tokens from the pull-parser, so we can do
copy(JSONTokenizer(json), JSONWriter(stdout));
* Additionally provide an easier user API: JSONWriter.startObject(),
JSONWriter.startArray(), JSONWriter.writeField(name, T),...
2) DOM API
* It should of course be possible to manipulate the DOM, then write
it back
* Should be the same as the input DOM API
* Should be based on 2)
optional, nice-to have:
3) A simple serialization API
* counterpart to the deserialization API
* Shouldn't allocate any memory
* Based on output-ranges and 1)
* Usage: myvariable.toJSON(stdout);
* Helper function using Appender: string json = myvariable.toJSON();
Another questions is if and how this should interact with streams, if
we ever get them.
This list is quite long. As you see the demands are quite high and
therefore it will be a difficult and
Re: parseJSON bug
On Thursday, 8 August 2013 at 21:40:46 UTC, David wrote: Am 08.08.2013 22:15, schrieb Tofu Ninja: On Thursday, 8 August 2013 at 18:31:52 UTC, David wrote: Am 08.08.2013 20:24, schrieb Adam D. Ruppe: On Thursday, 8 August 2013 at 17:33:38 UTC, David wrote: I made a pull request improving the API a few weeks ago, no one seems to really care. Phobos needs a new dictator. Either that, or I will soon start my own standard lib and stop caring about phobos. I think, I even know a few who would help me... It is really bad that people are actually talking about starting there own standard lib, I wasn't around for the whole phobos vs tango thing but from what I hear, it wasn't pretty. If there is problems with phobos or the way its managed, I feel like we should try and fix them and not try to replace it. phobos is actually useable, still I don't like many of its design choices. I feel the same with D. D itself is better than most languages, I still think there is a long way to go, but official D people seem like it's enough and block progress (e.g. @property/-property the whole situation is a mess, but instead of properly reimplementing it, they try to fix an already broken system and break code with it, why not break code once, but replace it with a proper system) I can understand how you feel, I do sort of feel like people are way to scared of breaking changes and it causing things that badly need to be fix to not be... but still, I don't think a whole new standard lib would do much good
Re: parseJSON bug
On Thursday, 8 August 2013 at 22:19:28 UTC, Johannes Pfau wrote: I'd like to explain the special issue we have with std.json - as far as I understand it: *snip* This actually brings up the main beefs I have with the phobos dev process: 1) your requirements list should be prominently documented, so people considering writing something for phobos know what is needed up front 2) what's considered for phobos and what is just outside its scope? 3) these processes should be more authoritative than as far as I understand it - then new people could get involved with reviewing too, since they have an objective list of stuff to be on the lookout for and don't have to wait for someone else to come along and say something 4) phobos lets the perfect be the enemy of the good. std.json really isn't that bad, and ~50 lines of prettier add-on API could make it nicer, but instead of doing that we wait years for something that doesn't seem to be happening at all. * the orignal author is no longer around. AFAICS there's nobody feeling responsible for this module. This is a problem too: a module shouldn't be in the hands of one person. If any random contributor follows the documented rules, they should get their code pulled in. Since phobos is a community project, I think we should all be equally responsible for every part of it. One person might take the lead and do most the work but it shouldn't be *exclusive*, so if that one person can't or won't do something, someone else can just do it.
Re: parseJSON bug
Am 09.08.2013 00:19, schrieb Johannes Pfau: Am Thu, 08 Aug 2013 22:15:28 +0200 schrieb Tofu Ninja emmo...@purdue.edu: On Thursday, 8 August 2013 at 18:31:52 UTC, David wrote: Am 08.08.2013 20:24, schrieb Adam D. Ruppe: On Thursday, 8 August 2013 at 17:33:38 UTC, David wrote: I made a pull request improving the API a few weeks ago, no one seems to really care. Phobos needs a new dictator. Either that, or I will soon start my own standard lib and stop caring about phobos. I think, I even know a few who would help me... It is really bad that people are actually talking about starting there own standard lib, I wasn't around for the whole phobos vs tango thing but from what I hear, it wasn't pretty. If there is problems with phobos or the way its managed, I feel like we should try and fix them and not try to replace it. I'm sorry that you've had such bad experiences when contributing to phobos. I think this is less of a phobos than a std.json problem. I'd like to explain the special issue we have with std.json - as far as I understand it: I think the problem is, people are afraid that changes will hurt D. The mentallity to improve D and make it awsome is lost (at least if feels like it), now all what is left WE NEED TO MAKE D PRODUCTION READY!!!111 COMPANIES USE D which makes sense, but one shouldn't forget why D was invented, to improve the programming situation and craft a language which is superior to all others and which allows to write simple clean but yet powerful code!
Re: std.json parsing real numbers.
On Thu, 08 Aug 2013 20:46:15 +0200 Borislav Kosharov boby_...@abv.bg wrote: On Thursday, 8 August 2013 at 16:05:56 UTC, Nick Sabalausky wrote: On Thu, 08 Aug 2013 17:20:16 +0200 Borislav Kosharov bo...@gmail.com wrote: On Thursday, 8 August 2013 at 10:13:51 UTC, khurshid wrote: I wrote not a 1.24E+1, a 1 .24E +1 with leading spaces. Well what should it be if it's not 12.4? A syntax error. I don't think this would cause any problems. It would just throw syntax error because there is white-space between? It would be just annoying to get syntax error because of extra white-space. Maybe this is one of the situations where we should think It's not a bug, it's a feature! Unless there is a situation that would make no sense to work or something, it should be left like it is now. Specs should be adhered to strictly. Otherwise you can wind up in the antirobustness principle situation like late 90's HTML. Laxness begets more laxness...and then incompatibility bugs.
Re: UFCS for templates
On Thursday, 8 August 2013 at 17:55:04 UTC, Dicebot wrote:
On Thursday, 8 August 2013 at 17:35:02 UTC, JS wrote:
Can we have UFCS for templates?
e.g.,
T New(T, A...)(A args) { }
T t = T.New(args);
Note, in this case, the type parameter is substituted.
As always, providing motivating use case and advantage/cost
comparison is usual requirement to make something happen.
DIP's exist for a reason.
Are you not smart enough to come up with use cases yourself? This
is not some extremely rare thing that might be used 1 in 10^100.
Anything up for formal review?
According to the review queue, there there are 5 items that are currently ready for review. There was even a thread a while back about starting another formal review, where both Jacob Carlborg and Brian Schott said they're ready for review: http://forum.dlang.org/thread/gjonxudcdiwrlkgww...@forum.dlang.org (it mostly digressed into bickering about the review process...). Is there currently a formal review under way? I'm particularly interested in the outcome of the formal review of std.serialize, because I'd like to see a decent replacement for std.json (I'd be willing to contribute as well). I havn't seen anything in this mailing list (except the above and one by Walter Bright) for a while, and I haven't seen any pull requests for any of the items in the review queue.
Re: UFCS for templates
On Friday, 9 August 2013 at 00:34:31 UTC, JS wrote: Are you not smart enough to come up with use cases yourself? This is not some extremely rare thing that might be used 1 in 10^100. It's not his proposal. The burden of proof is on you.
Re: Anything up for formal review?
On Friday, 9 August 2013 at 00:53:18 UTC, Tyler Jameson Little wrote: According to the review queue, there there are 5 items that are currently ready for review. There was even a thread a while back about starting another formal review, where both Jacob Carlborg and Brian Schott said they're ready for review: http://forum.dlang.org/thread/gjonxudcdiwrlkgww...@forum.dlang.org (it mostly digressed into bickering about the review process...). Is there currently a formal review under way? I'm particularly interested in the outcome of the formal review of std.serialize, because I'd like to see a decent replacement for std.json (I'd be willing to contribute as well). I havn't seen anything in this mailing list (except the above and one by Walter Bright) for a while, and I haven't seen any pull requests for any of the items in the review queue. I'm also very interested in seeing the status of std.serialize. The lack of a serialization library in phobos is rather disappointing, and it would be nice to see the situation rectified. From what I can tell, orange/std.serialize seems quite nice, but I haven't personally tried it yet as I'd rather avoid third party dependencies and have been waiting for it to make it into phobos instead.
Re: UFCS for templates
On Friday, 9 August 2013 at 00:57:21 UTC, Mike Parker wrote: On Friday, 9 August 2013 at 00:34:31 UTC, JS wrote: Are you not smart enough to come up with use cases yourself? This is not some extremely rare thing that might be used 1 in 10^100. It's not his proposal. The burden of proof is on you. Um, not really... Do you think that god made some law that requires me to? If he, you, or anyone else doesn't think such a feature is a good idea then so be it... It' not my problem is you want the D language to suffer. At some point something better will come with better features and D will succumb and all the time you invested will be a waste. I would think that if you really cared about the D lang you would want it to be the best it can... In any case, I know very well that it is quite useless for me to make suggestions for D... but I'm definitely not going to sit here and type up use cases because you are too lazy, don't have the foresight, or don't care to think about the issue. The fact is, I'm most likely not going to be able to convince you to accept anything I say because: 1. Something only useful to you is acceptable. You don't find this useful because you haven't used this construct, hence it is not acceptable. (This is generally known as close minded) 2. Generally things I propose are simplifications of semantics. I like to work efficiently. My proposes can be accomplished long hand... and for you, that is good enough... Either because you do not use such semantics and hence get tired of the inefficiency or don't like simplifications because you inanely feel they take away from the language by adding too much overhead(in some form or another). So it is what it is. Take it or leave it. I've given the proposal, in maybe 10 years D will probably get around to having it... if it's still around at all.
A suggestion on keyword for_each
I suggest that change keyword *for_each* to *for* since *for* is clear enough and less letters, like C++11 does.
Re: UFCS for templates
So instead of: T t = New!T(args) you would like: T t = T.New(args) Is that it?
Re: UFCS for templates
On Friday, August 09, 2013 05:29:05 JS wrote: On Friday, 9 August 2013 at 00:57:21 UTC, Mike Parker wrote: On Friday, 9 August 2013 at 00:34:31 UTC, JS wrote: Are you not smart enough to come up with use cases yourself? This is not some extremely rare thing that might be used 1 in 10^100. It's not his proposal. The burden of proof is on you. Um, not really.. [snip] Actually, that is how it works. If you want a change made to the language, you have to convince the maintainers of the language that your proposed change is worth making. You can throw ideas out there all day if you want to, but changes are made because someone convinces the people in charge that they should be made. If we implemented every stray idea that was proposed, we'd constantly be implementing new ideas and never have a stable language. We also likely wouldn't a language that was worth using. Even if your idea is absolutely fantastic, you have to convince others of that, or it's not going anywhere. The attitude of take it or leave it when presenting an idea will pretty much always result in leave it. There are just too many ideas and too much to do for it to be otherwise. Also, you're coming across as being very combative and confrontational, and whether you mean to do that or not, it's not conducive to having a rational discussion or having the sort of collaborative environment that we're looking to have here. If you want others to listen to you or to convince anyone of anything around here, you may want to consider adjusting how you present things so that you and your arguments come across in a more favorable light. - Jonathan M Davis
