Re: RFC: scope and borrowing
On 24/08/14 15:14, "Marc Schütz" " wrote: In the "Opportunities for D" thread, Walter again mentioned the topics ref counting, GC, uniqueness, and borrowing, from which a lively discussion developed [1]. I took this thread as an opportunity to write down some ideas about these topics. The result is a rather extensive proposal for the implementation of borrowing, and its implementations: http://wiki.dlang.org/User:Schuetzm/scope I assume with this proposal it should be safe to do more stack allocations and have the compiler verify references don't escape the scope. Would there be a good idea to and a new function, besides the destructor, that will be called for variables declared as "scope" when they go out of scope. The problem with destructors are that they can be called both when an object is deleted by the GC and when an object goes of out scope. -- /Jacob Carlborg
Re: [OT] Microsoft filled patent applications for scoped and immutable types
On Tuesday, 26 August 2014 at 21:26:36 UTC, H. S. Teoh via Digitalmars-d wrote: D has had immutable for years! Surely that counts as prior art?? If the patent passes for whatever reason, this becomes a valid point if and only if you have the resources to contest its validity. The patent holder can effectively strongarm you into paying for licensing unless you have the (upwards of) hundreds of thousands of dollars needed for lawyer fees. They need only to drag out the court proceedings to starve you monetarily and win by walkover. It's not a far stretch to make an analogy to protection rackets, and it seems to me that the very point of patents has been subverted.
Re: git show "previous tag"
On 8/27/14, 9:47 PM, Andrew Edwards wrote: Anyone here knows how to consistently obtain the previous tag on git? Are tags always coming in order? Then it's easy: git tag | tail -n2 | head -n1 Andrei
Re: [OT] Microsoft filled patent applications for scoped and immutable types
On Wed, Aug 27, 2014 at 09:27:19PM -0700, Walter Bright via Digitalmars-d wrote: > On 8/27/2014 8:25 PM, jollie wrote: > >Walter Bright Wrote in message: > >>On 8/27/2014 12:50 PM, Idan Arye wrote: > >>>Aren't these the patent numbers? > >> > >>Nope. Too many digits. Tried them, the form rejected them. > >> > > > >Spoke too soon. A patent number has not been issued as far as I can > >tell. > >This is listed in the application database. From the USPTO FAQ: > > > >Does your database include data on pending patent applications? > > > >The database only includes data on Published Applications in > >accordance with the 18 month pre-grant publication rules. Pending > >patent applications where the applicant has elected to not publish > >prior to grant remain confidential. > > Yeah, and the form rejects all attempts to disclose prior art without > a patent number. > > Reminds me of obamacare.gov :-) Never ascribe to malice that which is adequately explained by incompetence. -- Napoleon Bonaparte ;-) (P.S. Yes, I know the quote has probably been misattributed to Napoleon, but I forgot who the real author is/was since I failed to update my sigs file last time.) T -- One reason that few people are aware there are programs running the internet is that they never crash in any significant way: the free software underlying the internet is reliable to the point of invisibility. -- Glyn Moody, from the article "Giving it all away"
git show "previous tag"
Anyone here knows how to consistently obtain the previous tag on git? Currently, the installer uses: git describe --abbrev=0 v2.067.0-b1^ This does not always retrieve the correct tag though. In this case the tag prior to v2.067.0-b1 is v2.066.0, however this command returns v2.066.0-b1. This causes a problem because v2.066.0-b1 broke the installer and cannot be used to build DMD. To get around this issue, I usually upload a different version of the compiler in place of v2.066.0-b1. This is not the ideal solution because anyone downloading that v2.066.0-b1.zip will not be getting something completely different. Assistance appreciated. Regards, Andrew
Re: [OT] Microsoft filled patent applications for scoped and immutable types
On 8/27/2014 8:25 PM, jollie wrote: Walter Bright Wrote in message: On 8/27/2014 12:50 PM, Idan Arye wrote: Aren't these the patent numbers? Nope. Too many digits. Tried them, the form rejected them. Spoke too soon. A patent number has not been issued as far as I can tell. This is listed in the application database. From the USPTO FAQ: Does your database include data on pending patent applications? The database only includes data on Published Applications in accordance with the 18 month pre-grant publication rules. Pending patent applications where the applicant has elected to not publish prior to grant remain confidential. Yeah, and the form rejects all attempts to disclose prior art without a patent number. Reminds me of obamacare.gov :-)
Re: Before we implement SDL package format for DUB
On 8/27/14, 5:25 AM, Gary Willoughby wrote: On Wednesday, 27 August 2014 at 10:51:28 UTC, Jonathan Marler wrote: I just had an "epiphany". I believe that if I added attributes to ASON, it would be a true superset of SDL. Meaning any SDL file would also be a valid ASON file. What kind of monster did I create! I accidently created a language that serves as both a superset of JSON and SDL? I didn't think that would be possible, expecially with such a little amount of extensions to JSON. Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. - Antoine de Saint-Exupery Then perfection in personal finance is easy to achieve :o). -- Andrei
Re: [OT] Microsoft filled patent applications for scoped and immutable types
Walter Bright Wrote in message: > On 8/27/2014 12:50 PM, Idan Arye wrote: >> Aren't these the patent numbers? > > Nope. Too many digits. Tried them, the form rejected them. > Spoke too soon. A patent number has not been issued as far as I can tell. This is listed in the application database. From the USPTO FAQ: Does your database include data on pending patent applications? The database only includes data on Published Applications in accordance with the 18 month pre-grant publication rules. Pending patent applications where the applicant has elected to not publish prior to grant remain confidential. --
Re: SWIG?
On Thursday, 28 August 2014 at 01:08:43 UTC, Scott Wilson wrote:
SWIG has D support. But it seems old and out of fashion.
Community here does not buzz about it much either. Whats the
word on the street about the quality of SWIG-D stuff?
Scott
PS thankyou Walter for replying
The swig bindings are good and I use them quite a bit to
interface with legacy C++ projects.
This might be fixed already, I don't know and haven't tracked it
but I had to make a minor change to the binding generator, as
shown below.
edit commoncore_im.d and change the following:
---
mixin template SwigOperatorDefinitions() {
...
static if (is(typeof(swigOpEquals(rhs {
return swigOpEquals(rhs);
} else {
...
---
to
---
mixin template SwigOperatorDefinitions() {
...
static if (is(typeof(swigOpEquals(rhs {
return cast(bool)(swigOpEquals(rhs)); // <-- cast(bool)
added
} else {
...
---
cheers, uri
Re: SWIG?
I've used it quite a bit for a number of bindings (opencv, sfml + many other libs). It's much easier than the conventional approach of manual bindings (eg deimos), especially to keep the port up to date with upstream changes. However the following should be worked on: * support for newly introduced C++ namespaces ( https://github.com/swig/swig/issues/213) * some support for multiple inheritance (I proposed using alias this in https://github.com/swig/swig/issues/98) * mapping of C++ templates to D templates in simple cases at least (the templates would have to be instantiated somewhere in source file of course to avoid linker errors). Only the function signature would be mapped, the implementation would be still on C++ side * miscellaneous compiler warnings that shouldn't be hard to deal with - Deprecation: Read-modify-write operations are not allowed for shared variables : has a pull request (https://github.com/swig/swig/issues/203 ) - missing override * it would help to have a dedicated bug tracker for D-swig. Currently github issues for swig lump all other languages together, making D-swig of limited visibility for D community. At least create a SWIG-D label in github issues. @klickverbot will tell you more as he implemented most of it IIRC On Wed, Aug 27, 2014 at 6:08 PM, Scott Wilson via Digitalmars-d < digitalmars-d@puremagic.com> wrote: > SWIG has D support. But it seems old and out of fashion. Community here > does not buzz about it much either. Whats the word on the street about the > quality of SWIG-D stuff? > > Scott > > PS thankyou Walter for replying >
Re: [OT] Microsoft filled patent applications for scoped and immutable types
Walter Bright Wrote in message: > On 8/27/2014 12:50 PM, Idan Arye wrote: >> Aren't these the patent numbers? > > Nope. Too many digits. Tried them, the form rejected them. > Application number : 13/734750 Patent number: 0196008 --
SWIG?
SWIG has D support. But it seems old and out of fashion. Community here does not buzz about it much either. Whats the word on the street about the quality of SWIG-D stuff? Scott PS thankyou Walter for replying
Re: Bug or what?
Am Wed, 27 Aug 2014 20:30:08 +
schrieb "Phil Lavoie" :
> On Wednesday, 27 August 2014 at 20:28:11 UTC, Phil Lavoie wrote:
> > On Wednesday, 27 August 2014 at 20:05:27 UTC, MacAsm wrote:
> >> On Wednesday, 27 August 2014 at 19:51:48 UTC, Phil Lavoie
> >> wrote:
> >>> Ok so me and one of my colleagues have been working on some
> >>> code at a distance. We both use dmd as the compiler. I am
> >>> under Windows, she OSX.
> >>>
> >>> It is not uncommon that she experiences more strictness in
> >>> the type system than I do. For example, something like this
> >>> does compile for me, but not for her:
> >>>
> >>> int func(size_t i)
> >>> {
> >>> return i;
> >>> }
> >>>
> >>> It passes my compilation. She gets an error msg about
> >>> implicit casting of uint to int. I'm just wondering... has
> >>> anybody else experienced that and what is the expected
> >>> behavior?
> >>>
> >>> Thanks,
> >>> Phil
> >>
> >> size_t is a typedef to unsigned (check out
> >> http://dlang.org/type.html). So this warning is correct. I
> >> don't get this warning too. Maybe it's the type-checking that
> >> does differ on OSX. Are you using same compiler version and
> >> flags?
> >
> > Yeah yeah I checked it out and we both use same versions and
> > everything. Basically, to bit word size coherent I should just
> > have writtent this instead:
> >
> > ptrdiff_t func(size_t i) {return i;}
> >
> > Though it is still somewhat unsafe, at least it behaves the
> > same on both our machines.
> >
> > Phil
>
> Note that the compiler behaves the same, the code, not
> necessarily.
In my opinion this should always give you a compiler warning,
as it is not portable to 64-bit:
uint func(size_t i) {return i;}
But that has been discussed and reported to death already :D
I'm also somewhat pedantic about assigning unsigned to signed
types and vice versa. Most of the times I'd rather change the
code so that I can keep using e.g. unsigned absolute values
instead of differences.
--
Marco
Re: RFC: std.json sucessor
On 8/26/2014 12:24 AM, Don wrote: On Monday, 25 August 2014 at 23:29:21 UTC, Walter Bright wrote: On 8/25/2014 4:15 PM, "Ola Fosheim Grøstad" " wrote: On Monday, 25 August 2014 at 21:24:11 UTC, Walter Bright wrote: I didn't know that. But recall I did implement it in DMC++, and it turned out to simply not be useful. I'd be surprised if the new C++ support for it does anything worthwhile. Well, one should initialize with signaling NaN. Then you get an exception if you try to compute using uninitialized values. That's the theory. The practice doesn't work out so well. To be more concrete: Processors from AMD have signalling NaN behaviour which is different from processors from Intel. And the situation is worst on most other architectures. It's a lost cause, I think. The other issues were just when the snan => qnan conversion took place. This is quite unclear given the extensive constant folding, CTFE, etc., that D does. It was also affected by how dmd generates code. Some code gen on floating point doesn't need the FPU, such as toggling the sign bit. But then what happens with snan => qnan? The whole thing is an undefined, unmanageable mess.
Re: Before we implement SDL package format for DUB
On Wed, Aug 27, 2014 at 12:30 PM, Nick Sabalausky via Digitalmars-d < digitalmars-d@puremagic.com> wrote: > Therefore, I think the main critera we should be looking at here, for any > of the possibilities, isn't "Does this language have flaws?" but rather "Is > this language *good enough* to be supported by DUB as a JSON alternative?" > The 'alternative' bit is the kicker. Personally, I don't believe DUB can succeed at having multiple supported config languages - one or the other will win out over time, and users will diverge. So no language would meet that bar (in my opinion). Mostly we are talking about JSON+stuff as an additional language... so can it be reframed as 'additional features you can use in your dub config file, that aren't strict JSON'? Framing things this way, you could (for example) switch DUB entirely over to ASON, and avoid the 'switching to a new language' arguments. DUB takes JSON, DUB also accepts not-strictly-JSON syntax like comments, etc.
Re: [OT] Microsoft filled patent applications for scoped and immutable types
On 8/27/2014 1:02 PM, "Jérôme M. Berger" wrote: So for patent number 20140196015, the application number is 13/734762 and for patent number 20140196008, the application number is 13/734750. Jerome "Required fields (Patent Number) cannot be empty or the data entered is incorrectly formatted." "The field contains over 9 characters which cannot be processed in the USPTO system."
Re: [OT] Microsoft filled patent applications for scoped and immutable types
On 8/27/2014 1:17 PM, Dicebot wrote: On Wednesday, 27 August 2014 at 20:08:45 UTC, Jérôme M. Berger wrote: Note however that as I understand it D does not have "immutable types" as claimed by patent 20140196008. The difference is that according to the patent the immutable attribute is given to the type and applies to all instances of this type, whereas in D the immutable attribute applies to an instance (I may be wrong about that one, since I haven't done anything in D for years even if I try to keep up with the forums). However, scala case classes should constitute prior art for this patent. Jerome In D it applies to type. When you "apply immutable to the instance" you in fact create new type on the fly by adding immutable qualifier to the existing one. But it can also be aliased to always be immutable. Right. immutable(T) declares a transitive immutable type.
Re: [OT] Microsoft filled patent applications for scoped and immutable types
On 8/27/2014 12:50 PM, Idan Arye wrote: Aren't these the patent numbers? Nope. Too many digits. Tried them, the form rejected them.
Re: Bug or what?
On Wednesday, 27 August 2014 at 20:28:11 UTC, Phil Lavoie wrote:
On Wednesday, 27 August 2014 at 20:05:27 UTC, MacAsm wrote:
On Wednesday, 27 August 2014 at 19:51:48 UTC, Phil Lavoie
wrote:
Ok so me and one of my colleagues have been working on some
code at a distance. We both use dmd as the compiler. I am
under Windows, she OSX.
It is not uncommon that she experiences more strictness in
the type system than I do. For example, something like this
does compile for me, but not for her:
int func(size_t i)
{
return i;
}
It passes my compilation. She gets an error msg about
implicit casting of uint to int. I'm just wondering... has
anybody else experienced that and what is the expected
behavior?
Thanks,
Phil
size_t is a typedef to unsigned (check out
http://dlang.org/type.html). So this warning is correct. I
don't get this warning too. Maybe it's the type-checking that
does differ on OSX. Are you using same compiler version and
flags?
Yeah yeah I checked it out and we both use same versions and
everything. Basically, to bit word size coherent I should just
have writtent this instead:
ptrdiff_t func(size_t i) {return i;}
Though it is still somewhat unsafe, at least it behaves the
same on both our machines.
Phil
Note that the compiler behaves the same, the code, not
necessarily.
Re: Bug or what?
On Wednesday, 27 August 2014 at 20:05:27 UTC, MacAsm wrote:
On Wednesday, 27 August 2014 at 19:51:48 UTC, Phil Lavoie wrote:
Ok so me and one of my colleagues have been working on some
code at a distance. We both use dmd as the compiler. I am
under Windows, she OSX.
It is not uncommon that she experiences more strictness in the
type system than I do. For example, something like this does
compile for me, but not for her:
int func(size_t i)
{
return i;
}
It passes my compilation. She gets an error msg about implicit
casting of uint to int. I'm just wondering... has anybody else
experienced that and what is the expected behavior?
Thanks,
Phil
size_t is a typedef to unsigned (check out
http://dlang.org/type.html). So this warning is correct. I
don't get this warning too. Maybe it's the type-checking that
does differ on OSX. Are you using same compiler version and
flags?
Yeah yeah I checked it out and we both use same versions and
everything. Basically, to bit word size coherent I should just
have writtent this instead:
ptrdiff_t func(size_t i) {return i;}
Though it is still somewhat unsafe, at least it behaves the same
on both our machines.
Phil
Re: [OT] Microsoft filled patent applications for scoped and immutable types
On 8/27/2014 5:20 AM, Chris wrote: On Wednesday, 27 August 2014 at 03:00:26 UTC, Nick Sabalausky wrote: Nice. I've heard that a lot of the scenery is stunning over there, too. Slow and expensive electronics importing AIUI, but maybe that'd be in my best interest anyway...biggest thing to raise my blood pressure lately was my last trip to MicroCenter[1]. Take it easy. The most important things are the ideas and the software. The latests gadgets are for users :-) Unfortunately I need to use those gadgets in order to write software on/for them. :/ Heh, man, all I wanted was to find a reasonable inexpensive laptop, that won't choke on Linux, and be certain VT-x was supported in the big three: CPU, mainboard and BIOS. (And the CPU I was looking at supports VT-d too, so I was curious to see if it was actually *usable*, ie not blocked by lack of support in mainboard/BIOS, 'cause that could influence my choice of exact model.) Back in the 90's that all would have been trivial: Slap CPUID (or some 90's equivalent thereof) onto the machine and run it. Heck, published specs used to be detailed and, well, somewhat less unreliable. But these days everyone's so afraid of their own shadow, they've got everything locked down so tightly that the demo units may as well be cardboard props. And expecting published spec to be both complete and accurate? Pfft. No buzzwords == hide the info. And then there's having to hear all of the dumb things coming out of the sales monkeys mouths. Like the password-protected windows admin account being referred to as a "firewall". Or the word "cloud" used for freaking *everything* (with no utterance of the *real* word: "Internet"). And *all* the verbal nonsense always coming with a heavy dose of suited-smugness and self-assuredness. 'Course, I blame "portlandian" silicon valley for that whole "cloud" bs. But whatever. And then there's all the glare-magnet fingerprinted glossy half-height screens, DRM and lockouts to deal with even *after* you buy it, basic-yet-still-missing features that some suit decided I don't need because it saves twenty cents, etc, etc...Ugh. Computing used to be fun. Now it's just corporate paranoia, warring and idiocy. And that's just *real* computers, I haven't even mentioned "phones"... As soon as I finally snap and go all luddite hermit or something, maybe that's where I'll retire ;) New Zealand that is, not MicroCenter. Swapping your chip for sheep. Sheep are fuzzy!! And tasty! I like! :)
Re: [OT] Microsoft filled patent applications for scoped and immutable types
On Wednesday, 27 August 2014 at 20:08:45 UTC, Jérôme M. Berger wrote: Note however that as I understand it D does not have "immutable types" as claimed by patent 20140196008. The difference is that according to the patent the immutable attribute is given to the type and applies to all instances of this type, whereas in D the immutable attribute applies to an instance (I may be wrong about that one, since I haven't done anything in D for years even if I try to keep up with the forums). However, scala case classes should constitute prior art for this patent. Jerome In D it applies to type. When you "apply immutable to the instance" you in fact create new type on the fly by adding immutable qualifier to the existing one. But it can also be aliased to always be immutable.
Re: [OT] Microsoft filled patent applications for scoped and immutable types
Note however that as I understand it D does not have "immutable types" as claimed by patent 20140196008. The difference is that according to the patent the immutable attribute is given to the type and applies to all instances of this type, whereas in D the immutable attribute applies to an instance (I may be wrong about that one, since I haven't done anything in D for years even if I try to keep up with the forums). However, scala case classes should constitute prior art for this patent. Jerome
Re: Bug or what?
On Wednesday, 27 August 2014 at 19:51:48 UTC, Phil Lavoie wrote:
Ok so me and one of my colleagues have been working on some
code at a distance. We both use dmd as the compiler. I am under
Windows, she OSX.
It is not uncommon that she experiences more strictness in the
type system than I do. For example, something like this does
compile for me, but not for her:
int func(size_t i)
{
return i;
}
It passes my compilation. She gets an error msg about implicit
casting of uint to int. I'm just wondering... has anybody else
experienced that and what is the expected behavior?
Thanks,
Phil
size_t is a typedef to unsigned (check out
http://dlang.org/type.html). So this warning is correct. I don't
get this warning too. Maybe it's the type-checking that does
differ on OSX. Are you using same compiler version and flags?
Re: Bug or what?
On Wednesday, 27 August 2014 at 19:56:29 UTC, Brian Schott wrote:
On Wednesday, 27 August 2014 at 19:51:48 UTC, Phil Lavoie wrote:
Ok so me and one of my colleagues have been working on some
code at a distance. We both use dmd as the compiler. I am
under Windows, she OSX.
It is not uncommon that she experiences more strictness in the
type system than I do. For example, something like this does
compile for me, but not for her:
int func(size_t i)
{
return i;
}
It passes my compilation. She gets an error msg about implicit
casting of uint to int. I'm just wondering... has anybody else
experienced that and what is the expected behavior?
Thanks,
Phil
size_t is different on 32-bit and 64-bit systems. If she's
building 64-bit binaries on OS-X and you're building 32-bit
binaries on Windows you could see different messages.
Either way, size_t is unsigned, int is signed, and you should
probably be getting the warning as well.
All right thanks Brian you were right on point.
I 32 she 64.
Indeed, I should have gotten a a warning because it is unsafe.
When I emit code for 64 bit machine I get the error messages she
does, which at least allows me to avoid making her compilation
fail.
Thanks again Brian!
Phil
Re: [OT] Microsoft filled patent applications for scoped and immutable types
Walter Bright wrote: > On 8/26/2014 2:30 PM, Brad Anderson wrote: >> On Tuesday, 26 August 2014 at 21:26:36 UTC, H. S. Teoh via Digitalmars-d >> wrote: >>> D has had immutable for years! Surely that counts as prior art?? Does >>> the patent office accept prior art submissions? >>> >>> >>> T >> They do. >> >> http://meta.patents.stackexchange.com/a/107 > > Well, I attempted to make a filing of prior art. The application form > requires > an "application number" and a "patent number". I can't find the patent > number, > and the form rejects my filing. > > https://efs.uspto.gov/EFSWebUIUnregistered/EFSWebUnregistered?ActionString=go.Begin The patent number is the one in the "Document type and number" field, where it says "United States Patent Application " (even though it says "application" in the text) and the application number is the one in the "Application number" field. So for patent number 20140196015, the application number is 13/734762 and for patent number 20140196008, the application number is 13/734750. Jerome
Re: Bug or what?
On Wednesday, 27 August 2014 at 19:51:48 UTC, Phil Lavoie wrote:
Ok so me and one of my colleagues have been working on some
code at a distance. We both use dmd as the compiler. I am under
Windows, she OSX.
It is not uncommon that she experiences more strictness in the
type system than I do. For example, something like this does
compile for me, but not for her:
int func(size_t i)
{
return i;
}
It passes my compilation. She gets an error msg about implicit
casting of uint to int. I'm just wondering... has anybody else
experienced that and what is the expected behavior?
Thanks,
Phil
size_t is different on 32-bit and 64-bit systems. If she's
building 64-bit binaries on OS-X and you're building 32-bit
binaries on Windows you could see different messages.
Either way, size_t is unsigned, int is signed, and you should
probably be getting the warning as well.
Re: [OT] Microsoft filled patent applications for scoped and immutable types
On Wednesday, 27 August 2014 at 19:35:38 UTC, Walter Bright wrote: On 8/26/2014 2:30 PM, Brad Anderson wrote: On Tuesday, 26 August 2014 at 21:26:36 UTC, H. S. Teoh via Digitalmars-d wrote: D has had immutable for years! Surely that counts as prior art?? Does the patent office accept prior art submissions? T They do. http://meta.patents.stackexchange.com/a/107 Well, I attempted to make a filing of prior art. The application form requires an "application number" and a "patent number". I can't find the patent number, and the form rejects my filing. https://efs.uspto.gov/EFSWebUIUnregistered/EFSWebUnregistered?ActionString=go.Begin There is a number in the patents' page at http://www.freepatentsonline.com labeld under "Document Type and Number": Title: DECLARATION OF LIFETIME OF RESOURCE REFERENCE Document Type and Number: United States Patent Application 20140196015 Title: IMMUTABLE OBJECT TYPES Document Type and Number: United States Patent Application 20140196008 Aren't these the patent numbers?
Re: How do I translate this bit of code from C(using pointers) to D?
On Tuesday, 26 August 2014 at 21:29:04 UTC, H. S. Teoh via
Digitalmars-d wrote:
On Tue, Aug 26, 2014 at 08:58:13PM +, MacAsm via
Digitalmars-d wrote:
It maybe trivial to most of you but I don't know how do this
avoiding
string duplications. Can someone help me?
[...]
in D, I can wrote as following:
[...]
void move(int n)
{
prev = str; // <- I want to avoid this string duplication
did in every move() call
This does not duplicate the string. You may find this article
helpful:
http://dlang.org/d-array-article.html
Thanks. This is exactly what I was worried about. If no string
duplciation is done I think this D code is just fine...
Bug or what?
Ok so me and one of my colleagues have been working on some code
at a distance. We both use dmd as the compiler. I am under
Windows, she OSX.
It is not uncommon that she experiences more strictness in the
type system than I do. For example, something like this does
compile for me, but not for her:
int func(size_t i)
{
return i;
}
It passes my compilation. She gets an error msg about implicit
casting of uint to int. I'm just wondering... has anybody else
experienced that and what is the expected behavior?
Thanks,
Phil
Re: Before we implement SDL package format for DUB
On 8/27/2014 3:26 PM, Idan Arye wrote: I don't like `dub describe --normalize` - it implies that the regular `dub describe` is in some non-normalize format and adding this flag will normalize the output. If you want to add normalization as a `dub describe` flag, I'd prefer something like `dub describe --buildfile-only` Yea, that's better. I just meant "Maybe a flag for 'describe' rather than a separate dub command." and didn't feel like coming up with an alternative name. :)
Re: Before we implement SDL package format for DUB
On 8/27/2014 12:57 PM, Gary Willoughby wrote: D and its tools are crying out for stability right now. Change for change sake has seriously hurt D in the past. It's also been a critical factor in it's success. Double-edged sword, admittedly.
Re: [OT] Microsoft filled patent applications for scoped and immutable types
On 8/26/2014 2:30 PM, Brad Anderson wrote: On Tuesday, 26 August 2014 at 21:26:36 UTC, H. S. Teoh via Digitalmars-d wrote: D has had immutable for years! Surely that counts as prior art?? Does the patent office accept prior art submissions? T They do. http://meta.patents.stackexchange.com/a/107 Well, I attempted to make a filing of prior art. The application form requires an "application number" and a "patent number". I can't find the patent number, and the form rejects my filing. https://efs.uspto.gov/EFSWebUIUnregistered/EFSWebUnregistered?ActionString=go.Begin
Re: Before we implement SDL package format for DUB
On 8/27/2014 5:27 AM, Sönke Ludwig wrote:
Am 27.08.2014 10:02, schrieb Kagamin:
On Wednesday, 27 August 2014 at 02:24:46 UTC, Nick Sabalausky wrote:
That's somewhat misleading.
More accurately, SDL is newline-delimited (with backslash line
continuation). That's pretty darn simple and has an age-old history.
It's not like we're talking weird Python/JavaScript rules or anything
here.
The only thing that does trip people up is that the existence of { and
} in the syntax makes people think "C-family and therefore freeform".
And then it isn't, so that makes them angry. "Yeeargh! Hulk Not Want!"
Well...or something vaguely sorta kinda like that ;)
That's justified, because SDL fails to not surprise. Curly brace
syntaxes are not line-delimited not requires backslash line
continuations.
Yea, I'll grant it *is* somewhat of a blemish in SDL's design. But I
don't think it's a critical one.
Besides, this thread's (dare I say "bikeshedded"?) quest for an ideal
data language seems doomed from the start: If we try to avoid the less
common ones, and avoid inventing our own (which I think we have good
reason to avoid), then everything left *does* have imperfections.
Therefore, I think the main critera we should be looking at here, for
any of the possibilities, isn't "Does this language have flaws?" but
rather "Is this language *good enough* to be supported by DUB as a JSON
alternative?"
Like JavaScript for example?
Heh, there is that.
What's wrong with XML? I work with it daily and see no problem. The less
syntax a language has, the worse it scales, and if it doesn't scale, its
adoption creates a technical debt. 100 lines with 3 levels of nesting
and JSON becomes hard to follow and TOML becomes simply unmanageable.
The reason to search for an additional format is to make it more
convenient and readable for human interaction. XML wouldn't structurally
a bad choice, but is awful because of it's syntactical overhead.
That's a big one. *The* big one in my mind.
Additionally, despite XML's simplistic appearance, some of the details
about it get disturbingly over-engineered. Heck, take a look at W3C's
docs on it: for something that's *supposed* to be as simple as:
blah
For something that *appears* to be that simple, it's formal reality is
horrifically complicated.
Besides, there's nothing stopping a good editor from taking this:
{
"tag1" : {
...blah, blah, blah, blah...
...blah, blah, blah, blah...
...blah, blah, blah, blah...
...blah, blah, blah, blah...
}
}
And adding helper visuals (not part of the actual document) to display
it as this:
{
"tag1" : {
...blah, blah, blah, blah...
...blah, blah, blah, blah...
...blah, blah, blah, blah...
...blah, blah, blah, blah...
} "tag1"
} {root}
(The wouldn't be displayed, I just put them there to indicate
the text inside would be visually distinguished so that the user finds
it obvious it's not actually part of the document. Can't really emulate
that in a NG post.)
I don't know why no editors ever do that.
Re: RFC: scope and borrowing
On Tuesday, 26 August 2014 at 22:53:30 UTC, Marco Leise wrote: You could try to formalize some error messages and how the compiler's reasoning would go. What happens when I pass identifiers to scope!(…) return types? - Can the compiler look up the identifiers' types and scopes in all cases? It has to be able to. If a non-visible identifier is specified, it is an error. - Will the compiler deduce the return type from these identifiers? E.g. "scope!(someString) ref getString();" will work like in your example? I don't think so, because the "lifetime identifiers" could be structs containing the returned type. I see, this was a stupid mistake. Of course this function needs to specify the full type, as no type deduction can happen when the body isn't available. Fixed in on the Wiki. - What if we used incompatible types like "scope!(someString, someIntPtr)" there? - What about variables? Just to be sure: You can only specify variables as owners, not types. I've clarified this on the Wiki. static int someInt = 32; string someString; scope!(someString, someInt) int* x; x = &someInt; Is the declaration of x in error? Strings don't contain integers unless unsafe casts are used, so why would they narrow the lifetime of an integer reference? This is an interesting thought... But I would still allow this for a different reason. At the beginning, I only thought about `scope` as a tool for memory management, but I believe it can be applied for lifetime management of arbitrary resources. Let's slightly modify your example, and use different types: Task someProcess; scope!someProcess HANDLE my_handle; `someProcess` could represent an external process that is managed by this program, and `my_handle` could refer to some kind of object in this external process. This handle is only valid as long as the process exists, even though it is not a memory reference, and `Task` might not contain any members of type `HANDLE`. (This is not an ideal example, of course, because the process could terminate for reasons outside of our control.) A similar example would be a connection to the X server, and a handle to an object allocated from it. I already wrote this idea into the section "scope for non-reference types", with a simpler example. In fact, I believe that the entire proposal will be a bit simpler if references/pointers aren't treated specially. - Is it necessary to keep around all declared lifetime identifiers? In the snippet above (assuming it is valid), it looks like the shorter lived `someString' is enough to establish the semantics. Yes, it's possible to some degree, see the section "Considerations for the implementation". Unfortunately, this doesn't work with function declarations, and is incompatible with the suggested `scope!(const ...)` extension.
Re: [OT] Microsoft filled patent applications for scoped and immutable types
On Wed, Aug 27, 2014 at 11:59:12AM -0700, Walter Bright via Digitalmars-d wrote: > On 8/26/2014 12:37 PM, Max Klyga wrote: > >Microsoft being microsoft again. > > > >http://www.freepatentsonline.com/y2014/0196015.html - DECLARATION OF > >LIFETIME OF RESOURCE REFERENCE > >This contains description of scoped classes, etc. > > > >http://www.freepatentsonline.com/y2014/0196008.html - IMMUTABLE > >OBJECT TYPES > > > >I really hope patent office will reject these applications. > > > > The first release of D 2.000 in 2007 had transitive immutable types in > it. Since you're the inventor of D, perhaps it would be best if you could submit a prior art submission to the patent office? (Somebody has already posted links earlier in this thread where you can submit it to them directly.) T -- May you live all the days of your life. -- Jonathan Swift
Re: Before we implement SDL package format for DUB
On Wednesday, 27 August 2014 at 19:06:29 UTC, Nick Sabalausky
wrote:
On 8/27/2014 2:38 PM, Idan Arye wrote:
On Wednesday, 27 August 2014 at 01:51:54 UTC, Nick Sabalausky
wrote:
On 8/25/2014 6:14 PM, Idan Arye wrote:
On Monday, 25 August 2014 at 16:40:10 UTC, Jonathan Marler
wrote:
Hello everyone,
I've been working on SDL support for DUB and wanted to get
some
people's opinions on whether we should really use SDL.
I've posted my
thoughts here:
http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/2263/
You said that "The standard way to read a dub package
description is to
use the output of "dub describe", not to parse dub.json
directly", but
what about tools that *write* to dub.json?
...They *continue* writing to dub.json just as before?
I don't see the problem. "dub describe" isn't going to
magically start
failing just because it was a machine that wrote to dub.json
instead
of a human.
You did catch the part where people keep saying that support
for JSON
is *not going anywhere*, right?
> Currently, if an IDE wants to
use DUB behind the scenes as it's build system it can parse
dub.json and
modify it as it wishes, and that should even work if someone
modified
dub.json by hand. But what if someone modifies dub.json by
hand and adds
ASON stuff to it?
Again, use "dub describe" to read the data, then write to
"dub.{whatever}".
> I think we need a command like `dub normalize` that'll
"dub describe"
convert the dub.json file into a pure JSON file
"dub describe"
>that has exactly the
same data, so IDEs could call it before loading dub.json.
I don't see the problem.
`dub describe` does not give you a normalized version of
"dub.json". It
gives you something else:
$ dub init
Successfully created an empty project in '/tmp/dub-test'.
$ dub describe > dub.json.new
$ mv dub.json.new dub.json
$ dub describe
Error executing command describe: Got .name of type undefined
- expected
string.
Ok, I see now. Yea, that could be improved. Luckily it
shouldn't be a difficult feature to add, though.
`dub describe` is perfect for automated tools that want to
query DUB,
but it's not a solution for tools that need to modify it.
Well, it would probably work, it just wouldn't be an ideal
solution. But again, that "dub normalize" you suggest (or "dub
describe --normalize" or something) should do the trick. So it
doesn't appear to be a deal-breaker for supporting another
language, it's just an additional TODO for dub.
I don't like `dub describe --normalize` - it implies that the
regular `dub describe` is in some non-normalize format and adding
this flag will normalize the output. If you want to add
normalization as a `dub describe` flag, I'd prefer something like
`dub describe --buildfile-only`
Re: Before we implement SDL package format for DUB
On 8/27/2014 2:38 PM, Idan Arye wrote:
On Wednesday, 27 August 2014 at 01:51:54 UTC, Nick Sabalausky wrote:
On 8/25/2014 6:14 PM, Idan Arye wrote:
On Monday, 25 August 2014 at 16:40:10 UTC, Jonathan Marler wrote:
Hello everyone,
I've been working on SDL support for DUB and wanted to get some
people's opinions on whether we should really use SDL. I've posted my
thoughts here:
http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/2263/
You said that "The standard way to read a dub package description is to
use the output of "dub describe", not to parse dub.json directly", but
what about tools that *write* to dub.json?
...They *continue* writing to dub.json just as before?
I don't see the problem. "dub describe" isn't going to magically start
failing just because it was a machine that wrote to dub.json instead
of a human.
You did catch the part where people keep saying that support for JSON
is *not going anywhere*, right?
> Currently, if an IDE wants to
use DUB behind the scenes as it's build system it can parse dub.json and
modify it as it wishes, and that should even work if someone modified
dub.json by hand. But what if someone modifies dub.json by hand and adds
ASON stuff to it?
Again, use "dub describe" to read the data, then write to
"dub.{whatever}".
> I think we need a command like `dub normalize` that'll
"dub describe"
convert the dub.json file into a pure JSON file
"dub describe"
>that has exactly the
same data, so IDEs could call it before loading dub.json.
I don't see the problem.
`dub describe` does not give you a normalized version of "dub.json". It
gives you something else:
$ dub init
Successfully created an empty project in '/tmp/dub-test'.
$ dub describe > dub.json.new
$ mv dub.json.new dub.json
$ dub describe
Error executing command describe: Got .name of type undefined - expected
string.
Ok, I see now. Yea, that could be improved. Luckily it shouldn't be a
difficult feature to add, though.
`dub describe` is perfect for automated tools that want to query DUB,
but it's not a solution for tools that need to modify it.
Well, it would probably work, it just wouldn't be an ideal solution. But
again, that "dub normalize" you suggest (or "dub describe --normalize"
or something) should do the trick. So it doesn't appear to be a
deal-breaker for supporting another language, it's just an additional
TODO for dub.
Re: [OT] Microsoft filled patent applications for scoped and immutable types
On 8/26/2014 12:37 PM, Max Klyga wrote: Microsoft being microsoft again. http://www.freepatentsonline.com/y2014/0196015.html - DECLARATION OF LIFETIME OF RESOURCE REFERENCE This contains description of scoped classes, etc. http://www.freepatentsonline.com/y2014/0196008.html - IMMUTABLE OBJECT TYPES I really hope patent office will reject these applications. The first release of D 2.000 in 2007 had transitive immutable types in it.
Re: Before we implement SDL package format for DUB
On Wednesday, 27 August 2014 at 01:51:54 UTC, Nick Sabalausky
wrote:
On 8/25/2014 6:14 PM, Idan Arye wrote:
On Monday, 25 August 2014 at 16:40:10 UTC, Jonathan Marler
wrote:
Hello everyone,
I've been working on SDL support for DUB and wanted to get
some
people's opinions on whether we should really use SDL. I've
posted my
thoughts here:
http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/2263/
You said that "The standard way to read a dub package
description is to
use the output of "dub describe", not to parse dub.json
directly", but
what about tools that *write* to dub.json?
...They *continue* writing to dub.json just as before?
I don't see the problem. "dub describe" isn't going to
magically start failing just because it was a machine that
wrote to dub.json instead of a human.
You did catch the part where people keep saying that support
for JSON is *not going anywhere*, right?
> Currently, if an IDE wants to
use DUB behind the scenes as it's build system it can parse
dub.json and
modify it as it wishes, and that should even work if someone
modified
dub.json by hand. But what if someone modifies dub.json by
hand and adds
ASON stuff to it?
Again, use "dub describe" to read the data, then write to
"dub.{whatever}".
> I think we need a command like `dub normalize` that'll
"dub describe"
convert the dub.json file into a pure JSON file
"dub describe"
>that has exactly the
same data, so IDEs could call it before loading dub.json.
I don't see the problem.
`dub describe` does not give you a normalized version of
"dub.json". It gives you something else:
$ dub init
Successfully created an empty project in '/tmp/dub-test'.
$ dub describe > dub.json.new
$ mv dub.json.new dub.json
$ dub describe
Error executing command describe: Got .name of type undefined -
expected string.
Sure, the data to build a new "dub.json" is in there - after all,
all the data DUB can provide is in there. But that's the problem
- *all* the data DUB can provide is in there. That includes data
from downloaded dependencies, system data, (possibly) local
configuration data and anything can be added in the future.
That's the point of `dub describe` - query for anything DUB can
tell you and let the user pick what they need.
Even if the result of `dub describe` were valid for "dub.json",
you wouldn't want to put all that data in the project's
build-file! You want to be able to put "dub.json" under source
control and for that it must only contain information about the
project - not about the specific configuration of the machine of
the last developer who happened to run `dub describe` and
overwrite "dub.json".
`dub describe` is perfect for automated tools that want to query
DUB, but it's not a solution for tools that need to modify it.
Re: Before we implement SDL package format for DUB
On Wed, 27 Aug 2014 16:57:52 + Gary Willoughby via Digitalmars-d wrote: > D and its tools are crying out for stability right now. there is D1. stable as a doornail. signature.asc Description: PGP signature
Re: Before we implement SDL package format for DUB
On Wednesday, 27 August 2014 at 15:57:41 UTC, Jonathan Marler wrote: Even though you haven't added anything helpful... If you don't want input, don't publicly ask for it. Just because my input is not what you would deem helpful because it contradicts your view does not mean it's of no value. I always argue from a standpoint of zero change regarding anything to do with D and always will do. D and its tools are crying out for stability right now. Change for change sake has seriously hurt D in the past. Yes. dub is most definitely facing this problem at this minute. Where? in this *one* thread?
Re: [OT] Microsoft filled patent applications for scoped and immutable types
On 8/26/14, 12:37 PM, Max Klyga wrote: Microsoft being microsoft again. http://www.freepatentsonline.com/y2014/0196015.html - DECLARATION OF LIFETIME OF RESOURCE REFERENCE This contains description of scoped classes, etc. http://www.freepatentsonline.com/y2014/0196008.html - IMMUTABLE OBJECT TYPES I really hope patent office will reject these applications. Now on reddit: http://www.reddit.com/r/programming/comments/2eohiv/microsoft_filed_patent_applications_for_scoped Two links of interest you may want to contribute to: https://patents.stackexchange.com/questions/10128/prior-art-for-us-patent-application-20140196008-immutable-object-types https://patents.stackexchange.com/questions/10122/looking-for-prior-art-for-patent-application-us20140196015-declaration-of-lifet Andrei
Re: Before we implement SDL package format for DUB
On Wednesday, 27 August 2014 at 15:27:25 UTC, Gary Willoughby wrote: On Wednesday, 27 August 2014 at 15:07:22 UTC, Jonathan Marler wrote: IMO, ASON has a nice balance between being very simple and very nice for humans to write/maintain. I also think there are some JSON variants that do the same thing, json5 looks nice, but it doesn't support the SingularName feature that ASON does which would fix the nesting issue. I'm not necessarily arguing that Json is great or flexible. I'm arguing, well maybe arguing is a strong word, i'm positing that something more complicated than Json isn't really needed at this time. I understand the argument that it would be nice for human-friendly constructs to be present in the dub file but is this really a problem dub is facing at the minute? Yes. dub is most definitely facing this problem at this minute. Are lots of devs venting their spleens over not being able to include comments, heredoc strings and such in dub files? The dub registry is gaining traction lets not throw an obstacle in the road now. heredoc's is a new one, but comments/nesting/trailing commas/unquoted strings, yes, most assuredly yes. Have you not been reading people's concerns about JSON? How could you say that people aren't complaining? Also inventing a Frankenstein format that is both a superset of Json and SDL just sounds horrible and just sounds wrong. It's just too much. Your effort would be better directed to something which is an immediate problem. Not re-inventing this particular wheel. I most definitely wouldn't call ASON a "Frankenstein" format. I didn't design ASON to be a superset of SDL, that's just how it worked out. Just like YAML happens to be a superset of JSON. Instead of saying it "sounds horrible and just sounds wrong", why don't you look at the language spec and say what is wrong about it. It's fine if you think we shouldn't use a new language but even if no one ever uses it, it's helpful to know what features people think are good/bad so we can all learn something. Sonke has said Json will always be an option in dub. Which is fantastic because now that dub has reached an official level as the de-facto package manager we need to embrace stability and stop this needless change which has been plaguing D forever. Yes, JSON will always be used to represent the package format on the back-end. So it makes sense to allow users to use it on the front-end if they wish. And again, adding a new format isn't a "needless change", why do you think so many people have such strong opinions about what format to use. You seem to be one of the only ones that thinks adding a new format (or using "lenient JSON") is a bad thing. I honestly think Ason should be abandoned as an unneeded solution looking for a problem and something more stable and recognised like Yaml or XML, etc. implemented in future *if needed* and actually if requested by dub's users. You seem to be stuck on the idea that I think DUB should use ASON. I created this thread so I could learn from other people what they think about this format and others. Even though you haven't added anything helpful, after reading other people's posts I'm now leaning more towards SDl. My biggest complaint is that it might be confusing for people to go between the SDL version and the JSON version. However, Sonke thinks that he can make a much more friendly package format with SDL's extra features like tag values/attributes.
Re: Before we implement SDL package format for DUB
On Wednesday, 27 August 2014 at 15:07:22 UTC, Jonathan Marler wrote: IMO, ASON has a nice balance between being very simple and very nice for humans to write/maintain. I also think there are some JSON variants that do the same thing, json5 looks nice, but it doesn't support the SingularName feature that ASON does which would fix the nesting issue. I'm not necessarily arguing that Json is great or flexible. I'm arguing, well maybe arguing is a strong word, i'm positing that something more complicated than Json isn't really needed at this time. I understand the argument that it would be nice for human-friendly constructs to be present in the dub file but is this really a problem dub is facing at the minute? Are lots of devs venting their spleens over not being able to include comments, heredoc strings and such in dub files? The dub registry is gaining traction lets not throw an obstacle in the road now. Also inventing a Frankenstein format that is both a superset of Json and SDL just sounds horrible and just sounds wrong. It's just too much. Your effort would be better directed to something which is an immediate problem. Not re-inventing this particular wheel. Sonke has said Json will always be an option in dub. Which is fantastic because now that dub has reached an official level as the de-facto package manager we need to embrace stability and stop this needless change which has been plaguing D forever. I honestly think Ason should be abandoned as an unneeded solution looking for a problem and something more stable and recognised like Yaml or XML, etc. implemented in future *if needed* and actually if requested by dub's users.
Re: Before we implement SDL package format for DUB
On Wednesday, 27 August 2014 at 12:44:00 UTC, eles wrote: On Wednesday, 27 August 2014 at 12:25:43 UTC, Gary Willoughby wrote: On Wednesday, 27 August 2014 at 10:51:28 UTC, Jonathan Marler wrote: Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. - Antoine de Saint-Exupery Why to not use a classic? "Within C++, there is a much smaller and cleaner language struggling to get out." He meant, of course, D. We knew it all along. This is why dforums needs a like button:)
Re: Before we implement SDL package format for DUB
On Wednesday, 27 August 2014 at 13:32:56 UTC, Kagamin wrote:
On Wednesday, 27 August 2014 at 09:27:03 UTC, Sönke Ludwig
wrote:
That's justified, because SDL fails to not surprise. Curly
brace
syntaxes are not line-delimited not requires backslash line
continuations.
Like JavaScript for example?
You mean its feature where it can work without semicolons?
Yeah, that's a silly feature, but it's not forced on everyone.
I have never hit it in my code.
The reason to search for an additional format is to make it
more convenient and readable for human interaction. XML
wouldn't structurally a bad choice, but is awful because of
it's syntactical overhead.
Aren't people more concerned with writing XML rather than
reading? Syntax makes for easier reading and tedious writing.
And overhead is not really big:
"menu": { "id": "file", "value": "File" }
It's even shorter!
Yes writing it is what I'm concerned about. If you like XML
though, you're gonna love SDL:)
menu id="file" value="File"
It's even shorter again!
There's 1 to 1 mapping between SDL and XML, SDL just uses
curly-braces and newlines instead of the .
Re: Before we implement SDL package format for DUB
On Wednesday, 27 August 2014 at 12:25:43 UTC, Gary Willoughby wrote: On Wednesday, 27 August 2014 at 10:51:28 UTC, Jonathan Marler wrote: I just had an "epiphany". I believe that if I added attributes to ASON, it would be a true superset of SDL. Meaning any SDL file would also be a valid ASON file. What kind of monster did I create! I accidently created a language that serves as both a superset of JSON and SDL? I didn't think that would be possible, expecially with such a little amount of extensions to JSON. Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. - Antoine de Saint-Exupery On Wednesday, 27 August 2014 at 12:25:43 UTC, Gary Willoughby wrote: On Wednesday, 27 August 2014 at 10:51:28 UTC, Jonathan Marler wrote: I just had an "epiphany". I believe that if I added attributes to ASON, it would be a true superset of SDL. Meaning any SDL file would also be a valid ASON file. What kind of monster did I create! I accidently created a language that serves as both a superset of JSON and SDL? I didn't think that would be possible, expecially with such a little amount of extensions to JSON. Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. - Antoine de Saint-Exupery Nice quote, but unfortunately there's no such thing as a perfect programming language or a perfect data format. JSON is dirt simple and popular. However using strict JSON for build configuration prevents users from commenting out sections temporarily, and also rejects text that can be understood by a human but doesn't follow JSON's strict rules. It also becomes very unwieldy when any amount of nesting is involved. Then again, when you start writing data formats that are easier to write for humans, you start getting complicated. IMO, ASON has a nice balance between being very simple and very nice for humans to write/maintain. I also think there are some JSON variants that do the same thing, json5 looks nice, but it doesn't support the SingularName feature that ASON does which would fix the nesting issue.
Re: Before we implement SDL package format for DUB
On Wednesday, 27 August 2014 at 05:40:51 UTC, eles wrote:
On Wednesday, 27 August 2014 at 01:40:41 UTC, Nick Sabalausky
wrote:
All it would do is provide many tempting and creative ways to
accidentally obfuscate the package description file.
I agree partially with this, this is why I am not pushing for
D. A declarative language seems to be more appropriate in this
case.
Ideally we wouldn't even need that, but reality is rarely so
kind. I suppose if we can't be sufficiently Perl-like, maybe
Portage-like is the next best thing. :/
Thought dump:
The DUB package specification is versioned, right? So, in the
vein of the Package Manager Specification, for a given...let's
call it "DUBAPI version"... provide higher-level functions that
abstract away things that are common or things that are tricky to
get right if you try to always do them manually. Package them in
modules that can be imported and use the DUBAPI version within
the module to select version-specific behaviour. For those of
stern fortitude, an ugly ebuild-like thing; a...uhm, "dubuild":
DUBAPI=1;
import dub.autotools;
import dub.git;
import dub.utils : patch;
DESCRIPTION = "Plugin providing semi-solids for bread";
HOMEPAGE = "http://toa.st/spread";;
LICENSE = "zlib";
PHOBOS_VERSION = "<=2.065"; // TODO: fix the failure
GIT_REPO_URI = "http://github.com/toast/spread";;
GIT_BRANCH = "butter"; // Vars defined in the dub.git module
DEPEND = {">=libyeast-1.3", ">=libbread-2.2" }; // Build-time
dependency
// Each of these phase functions overrides a default.
// If it doesn't need overridden, the default is used.
src_unpack(){
git_fetch(GIT_BRANCH); // No argument gets master branch
patch("files/melt_butter.patch"); // Apply our local patch
}
src_configure() {
assert(autoreconf(), "configure failed!"); // Die if this
fails.
}
src_install() {
dub_install("~/toast/plugins/"); // Non-standard location
}
post_install() {
dublog("Activate the spread plugin under Tools -> Options ->
Plugins");
}
NOTE: I want to believe this is overkill and we'll never need to
consider anything even resembling this route, but experience
makes that hard.
-Wyatt
Re: Before we implement SDL package format for DUB
On Wednesday, 27 August 2014 at 09:27:03 UTC, Sönke Ludwig wrote:
That's justified, because SDL fails to not surprise. Curly
brace
syntaxes are not line-delimited not requires backslash line
continuations.
Like JavaScript for example?
You mean its feature where it can work without semicolons? Yeah,
that's a silly feature, but it's not forced on everyone. I have
never hit it in my code.
The reason to search for an additional format is to make it
more convenient and readable for human interaction. XML
wouldn't structurally a bad choice, but is awful because of
it's syntactical overhead.
Aren't people more concerned with writing XML rather than
reading? Syntax makes for easier reading and tedious writing.
And overhead is not really big:
"menu": { "id": "file", "value": "File" }
It's even shorter!
Re: Before we implement SDL package format for DUB
On Monday, 25 August 2014 at 22:14:59 UTC, Idan Arye wrote: About the language - if you are making a new data serialization language(NOT markup language. These languages don't actually mark anything up) for DUB, could you please make it support heredocs? This will allow, in the future, to easily add pre-build and post-build scripts directly in the build-file. If it's something non-trivial, it should be put into separate file at least to get dedicated syntax highlighting and editor support.
Re: Before we implement SDL package format for DUB
On Wednesday, 27 August 2014 at 12:25:43 UTC, Gary Willoughby wrote: On Wednesday, 27 August 2014 at 10:51:28 UTC, Jonathan Marler wrote: Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. - Antoine de Saint-Exupery Why to not use a classic? "Within C++, there is a much smaller and cleaner language struggling to get out." He meant, of course, D. We knew it all along.
Re: Before we implement SDL package format for DUB
On Wednesday, 27 August 2014 at 10:51:28 UTC, Jonathan Marler wrote: I just had an "epiphany". I believe that if I added attributes to ASON, it would be a true superset of SDL. Meaning any SDL file would also be a valid ASON file. What kind of monster did I create! I accidently created a language that serves as both a superset of JSON and SDL? I didn't think that would be possible, expecially with such a little amount of extensions to JSON. Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. - Antoine de Saint-Exupery
Re: Before we implement SDL package format for DUB
On Wednesday, 27 August 2014 at 11:29:32 UTC, Sönke Ludwig wrote: Am 27.08.2014 11:49, schrieb eles: But the next morning you'll wake up and regret what you did that night Well, that saying could be applied to so many things in life...
Re: RFC: scope and borrowing
Marco Leise:
The amount of possible use-cases you listed for this extension
is staggering.
With scope management in code like this:
import std.stdio, std.algorithm;
int foo(in int[] a) {
return sum([0, 1] ~ a[1 .. $ - 2] ~ 0 ~
[a[$ - 1] + 1, a[$ - 1] + 2]);
}
void main() {
int[5] b = [10, 20, 30, 40, 50];
b.foo.writeln;
}
The compiler in theory could lower the code to something like
this, removing all heap allocations for the array literals and
the concatenations, allowing 'foo' to be annotated with @nogc (I
don't know if Rust is able to do this, I presume it can):
import std.stdio, std.algorithm, core.stdc.stdlib;
T foo(T)(in T[] a) @nogc {
immutable size_t L = 2 + a.length - 3 + 1 + 2;
auto ptr = alloca(T.sizeof * L);
if (ptr == null)
exit(1); // Or throw a stack overflow error.
T[] b = (cast(T*)ptr)[0 .. L];
b[0] = 0;
b[1] = 1;
b[2 .. $ - 3] = a[1 .. $ - 2];
b[$ - 3] = 0;
b[$ - 2] = a[$ - 1] + 1;
b[$ - 1] = a[$ - 1] + 2;
return sum(b);
}
void main() {
int[5] c = [10, 20, 30, 40, 50];
c.foo.writeln;
}
But in some cases you don't want those arrays to be allocated on
the stack because you know they are very large. So the [...]s
array literal syntax becomes useful again:
import std.stdio, std.algorithm;
int foo(const scope int[] a) {
return sum([0, 1]s ~ a[1 .. $ - 2] ~ 0 ~
[a[$ - 1] + 1, a[$ - 1] + 2]s);
}
But this is still not enough, because even if those parts are all
safely stack-allocated, the result of the concatenation is still
not stack-allocated.
This could be enough:
import std.stdio, std.algorithm;
int foo(const scope int[] a) @nogc {
auto[$] a2 = [0, 1]s ~ a[1 .. $ - 2] ~ 0 ~
[a[$ - 1] + 1, a[$ - 1] + 2]s;
return sum(a2[]);
}
Bye,
bearophile
Re: Before we implement SDL package format for DUB
Am 27.08.2014 11:47, schrieb eles: On Wednesday, 27 August 2014 at 09:27:03 UTC, Sönke Ludwig wrote: Am 27.08.2014 10:02, schrieb Kagamin: On Wednesday, 27 August 2014 at 02:24:46 UTC, Nick Sabalausky wrote: The reason to search for an additional format is to make it more convenient and readable for human interaction. There is also this quest: http://www.gnu.org/software/recutils/ It seems to be missing built-in array types and nested maps/objects. It *looks* like it would require defining so many custom types that it would become a de-facto custom format. Still looks interesting in general, though.
Re: Before we implement SDL package format for DUB
Am 27.08.2014 11:49, schrieb eles: On Wednesday, 27 August 2014 at 09:33:19 UTC, Sönke Ludwig wrote: Am 27.08.2014 10:29, schrieb eles: On Wednesday, 27 August 2014 at 05:47:37 UTC, Nick Sabalausky wrote: On 8/27/2014 1:40 AM, eles wrote: On Wednesday, 27 August 2014 at 01:40:41 UTC, Nick Sabalausky wrote: On 8/26/2014 1:43 PM, eles wrote: On Tuesday, 26 August 2014 at 13:55:13 UTC, Sönke Ludwig wrote: Am 26.08.2014 15:37, schrieb eles: On Monday, 25 August 2014 at 19:35:09 UTC, Jonathan M Davis wrote: On Monday, 25 August 2014 at 18:31:42 UTC, Marc Schütz wrote: And you will have to pay the price for a rocket and have to rebuild parts of your house every time you kill a fly ;) If it's 3 AM and you cannot yet sleep because that fly is annoying you, I bet you'll consider that's a very small price to pay... But the next morning you'll wake up and regret what you did that night
Re: problem creating a 32-bit dll
Answering my own question: seems like the 32-bit binary gets linked against user32.lib even though I don't specify -Luser32.lib, but I have to specify that for the 64-bit build. On Wednesday, 27 August 2014 at 09:01:12 UTC, nezih wrote: but then does that mean the linker already link user32.lib? On Wednesday, 27 August 2014 at 05:42:06 UTC, kdmult wrote: On Tuesday, 26 August 2014 at 20:41:27 UTC, nezih wrote: Thanks! That did the trick. Btw do you have any idea about getting rid of the linker's warning message about the user32.lib? I played with the LIB env variable in several ways and I also edited sc.ini to set the LIB but no luck so far. Just remove -Luser32.lib from the command line.
Re: Before we implement SDL package format for DUB
I just had an "epiphany". I believe that if I added attributes to ASON, it would be a true superset of SDL. Meaning any SDL file would also be a valid ASON file. What kind of monster did I create! I accidently created a language that serves as both a superset of JSON and SDL? I didn't think that would be possible, expecially with such a little amount of extensions to JSON.
Re: [OT] Microsoft filled patent applications for scoped and immutable types
On Wednesday, 27 August 2014 at 09:36:30 UTC, Théo Bueno wrote: On Wednesday, 27 August 2014 at 09:28:17 UTC, monarch_dodra wrote: On Wednesday, 27 August 2014 at 09:20:49 UTC, Théo Bueno wrote: On Wednesday, 27 August 2014 at 09:08:24 UTC, Chris wrote: Of course, the whole lot of them! I only wonder who they're trying to attack here? It must be some sort of strategy to put someone they deem dangerous off his stride. Probably the open source community and / or a competitor. I don't know the laws in the US and don't know how serious this is. It probably can't just be ignored. Is there some other big company they're trying to get at with this? Maybe they're preparing a counter strike. Yeah, IMO these patents can't be a coincidence. Big companies file patents. All of them do. That's just the way it is. I wouldn't see anything more to it than that. It's not some conspiracy or corporate war. That's the way the game is played. We just need to make sure we don't become the losers here. It would help to have input from Walter here though: It's his language, and, AFAIK, he also happens to be savvy with this kind of stuff. Their brand new type qualifier is the same as D's one. They even copied the name "immutable". Maybe it's part of a strategy, maybe not. In any case it's a "thief", I don't like this word because you can't steal an idea, but they took ownership of it. From a linguistic point of view it is only logical one should come up with the word "immutable" in this context. If something (data, objects) are not "mutable" they are "immutable" (this may sound trivial but it is not). I suppose they filed the patent, because concurrency, thread safety and multi core programming have become so important over the last couple of years, and because it has become clear that some sort of "immutable" type is needed. Thus, they seek to get ownership of the word/idea/concept (which is ridiculous of course) to (pre-emptively) knock out others (or get money for it by licensing it to others, including those they stole it from). A shame, really.
Re: Before we implement SDL package format for DUB
On Wednesday, 27 August 2014 at 09:27:03 UTC, Sönke Ludwig wrote: Am 27.08.2014 10:02, schrieb Kagamin: On Wednesday, 27 August 2014 at 02:24:46 UTC, Nick Sabalausky wrote: The reason to search for an additional format is to make it more convenient and readable for human interaction. There is also this quest: http://www.gnu.org/software/recutils/
Re: Before we implement SDL package format for DUB
On Wednesday, 27 August 2014 at 09:33:19 UTC, Sönke Ludwig wrote: Am 27.08.2014 10:29, schrieb eles: On Wednesday, 27 August 2014 at 05:47:37 UTC, Nick Sabalausky wrote: On 8/27/2014 1:40 AM, eles wrote: On Wednesday, 27 August 2014 at 01:40:41 UTC, Nick Sabalausky wrote: On 8/26/2014 1:43 PM, eles wrote: On Tuesday, 26 August 2014 at 13:55:13 UTC, Sönke Ludwig wrote: Am 26.08.2014 15:37, schrieb eles: On Monday, 25 August 2014 at 19:35:09 UTC, Jonathan M Davis wrote: On Monday, 25 August 2014 at 18:31:42 UTC, Marc Schütz wrote: And you will have to pay the price for a rocket and have to rebuild parts of your house every time you kill a fly ;) If it's 3 AM and you cannot yet sleep because that fly is annoying you, I bet you'll consider that's a very small price to pay...
Re: [OT] Microsoft filled patent applications for scoped and immutable types
On Wednesday, 27 August 2014 at 09:28:17 UTC, monarch_dodra wrote: On Wednesday, 27 August 2014 at 09:20:49 UTC, Théo Bueno wrote: On Wednesday, 27 August 2014 at 09:08:24 UTC, Chris wrote: Of course, the whole lot of them! I only wonder who they're trying to attack here? It must be some sort of strategy to put someone they deem dangerous off his stride. Probably the open source community and / or a competitor. I don't know the laws in the US and don't know how serious this is. It probably can't just be ignored. Is there some other big company they're trying to get at with this? Maybe they're preparing a counter strike. Yeah, IMO these patents can't be a coincidence. Big companies file patents. All of them do. That's just the way it is. I wouldn't see anything more to it than that. It's not some conspiracy or corporate war. That's the way the game is played. We just need to make sure we don't become the losers here. It would help to have input from Walter here though: It's his language, and, AFAIK, he also happens to be savvy with this kind of stuff. Their brand new type qualifier is the same as D's one. They even copied the name "immutable". Maybe it's part of a strategy, maybe not. In any case it's a "thief", I don't like this word because you can't steal an idea, but they took ownership of it.
Re: [OT] Microsoft filled patent applications for scoped and immutable types
On Wednesday, 27 August 2014 at 09:28:17 UTC, monarch_dodra wrote: On Wednesday, 27 August 2014 at 09:20:49 UTC, Théo Bueno wrote: On Wednesday, 27 August 2014 at 09:08:24 UTC, Chris wrote: Of course, the whole lot of them! I only wonder who they're trying to attack here? It must be some sort of strategy to put someone they deem dangerous off his stride. Probably the open source community and / or a competitor. I don't know the laws in the US and don't know how serious this is. It probably can't just be ignored. Is there some other big company they're trying to get at with this? Maybe they're preparing a counter strike. Yeah, IMO these patents can't be a coincidence. Big companies file patents. All of them do. That's just the way it is. I wouldn't see anything more to it than that. It's not some conspiracy or corporate war. I don't share your optimism. That's the way the game is played. We just need to make sure we don't become the losers here. It would help to have input from Walter here though: It's his language, and, AFAIK, he also happens to be savvy with this kind of stuff.
Re: An idiom for disabling implicit conversions
On Tuesday, 26 August 2014 at 18:29:49 UTC, Uranuz wrote:
On Tuesday, 26 August 2014 at 16:48:08 UTC, Timon Gehr wrote:
On 08/26/2014 05:46 PM, Uranuz wrote:
In the pre-last paragraph please read text^
Also notice that C is language with weak type system but D is
declared to have type system.
as:
Also notice that C is language with weak type system but D is
declared to have *strong* type system.
It's not _that_ strong. Also, this is a library problem.
I'd suggest you file a bug report/enhancement request against
Phobos, if it is not already there.
https://issues.dlang.org/
It seems that adding some constructor(s)/opAssign(s) to
Nullable will solve this problem.
( BTW: You are more likely to get a quick response if your
post looks a little bit more digestible, like:
On 08/26/2014 05:38 PM, Uranuz could have written:
// ---
import std.typecons;
void main(){
Nullable!ubyte x;
Nullable!int y=x; // AssertError: Called 'get' on null
Nullable!ubyte
}
// ---
import std.typecons;
void main(){
Nullable!ubyte x;
Nullable!int y;
y=x; // AssertError: Called 'get' on null Nullable!ubyte
}
// ---
Is this a bug?
Or you could have gone straight to https://issues.dlang.org/.
:) )
The last example is even more obvious but didn't come to my
mind. Maybe I'l think of better implementation myself and push
something to standard library.
The best way to make something working is to do it myself
[jokingly]
If I could write multiple alias this in Nullable I could create
implicit conversions from Nullable!byte not only to byte but also
to Nullable!short, Nullable!int. In this case there is no need to
implement lots of overloads for property of type Nullable!int in
order to correctly accept Nullable!byte, Nullable!ubyte and so
on. I have wrote an example code and seems that only fixing
Nullable implementation will not help to eliminate the problem I
was talking about.
So I have a choice:
1. Implement Nullable type without *alias this* at all (and
access to internal value with getter method or property)
2. Implement lots of overloads of virtual Nullable!int property
to accept every minor integer types.
Also is needed to forbid Nullable!uint conversion because it is
incorrect. I can't correctly store uint.max inside int variable,
but implicit coversion is allowed in the compiler (and it is not
documented).
Because using alias this makes code shorter I prefer it, although
it is very tricky feature and needs attention during development.
Re: Before we implement SDL package format for DUB
Am 27.08.2014 10:29, schrieb eles: On Wednesday, 27 August 2014 at 05:47:37 UTC, Nick Sabalausky wrote: On 8/27/2014 1:40 AM, eles wrote: On Wednesday, 27 August 2014 at 01:40:41 UTC, Nick Sabalausky wrote: On 8/26/2014 1:43 PM, eles wrote: On Tuesday, 26 August 2014 at 13:55:13 UTC, Sönke Ludwig wrote: Am 26.08.2014 15:37, schrieb eles: On Monday, 25 August 2014 at 19:35:09 UTC, Jonathan M Davis wrote: On Monday, 25 August 2014 at 18:31:42 UTC, Marc Schütz wrote: All reasonable points, but it still seems like swatting a fly with a bazooka. ;) Well, you need a sharp eye and a sure hand. But otherwise, the sole problem is if the fly is on someone's nose... And you will have to pay the price for a rocket and have to rebuild parts of your house every time you kill a fly ;)
Re: Before we implement SDL package format for DUB
Am 27.08.2014 10:02, schrieb Kagamin:
On Wednesday, 27 August 2014 at 02:24:46 UTC, Nick Sabalausky wrote:
That's somewhat misleading.
More accurately, SDL is newline-delimited (with backslash line
continuation). That's pretty darn simple and has an age-old history.
It's not like we're talking weird Python/JavaScript rules or anything
here.
The only thing that does trip people up is that the existence of { and
} in the syntax makes people think "C-family and therefore freeform".
And then it isn't, so that makes them angry. "Yeeargh! Hulk Not Want!"
Well...or something vaguely sorta kinda like that ;)
That's justified, because SDL fails to not surprise. Curly brace
syntaxes are not line-delimited not requires backslash line continuations.
Like JavaScript for example?
- XML is XML. I find it actually OK.
I would support this. Yes, is verbose, we know that. But is a very solid
foundation.
XML is the spawn of satan. And not the cool "rock n roll", "heavy
metal" kind of satan, or the bumbling lovable DBZ "Mr. 'Hercule'
Satan" either, but the "hey, let's write a commercial webserver in
shell scripts" kind of raw pulsating evil.
What's wrong with XML? I work with it daily and see no problem. The less
syntax a language has, the worse it scales, and if it doesn't scale, its
adoption creates a technical debt. 100 lines with 3 levels of nesting
and JSON becomes hard to follow and TOML becomes simply unmanageable.
The reason to search for an additional format is to make it more
convenient and readable for human interaction. XML wouldn't structurally
a bad choice, but is awful because of it's syntactical overhead.
Re: [OT] Microsoft filled patent applications for scoped and immutable types
On Wednesday, 27 August 2014 at 09:20:49 UTC, Théo Bueno wrote: On Wednesday, 27 August 2014 at 09:08:24 UTC, Chris wrote: Of course, the whole lot of them! I only wonder who they're trying to attack here? It must be some sort of strategy to put someone they deem dangerous off his stride. Probably the open source community and / or a competitor. I don't know the laws in the US and don't know how serious this is. It probably can't just be ignored. Is there some other big company they're trying to get at with this? Maybe they're preparing a counter strike. Yeah, IMO these patents can't be a coincidence. Big companies file patents. All of them do. That's just the way it is. I wouldn't see anything more to it than that. It's not some conspiracy or corporate war. That's the way the game is played. We just need to make sure we don't become the losers here. It would help to have input from Walter here though: It's his language, and, AFAIK, he also happens to be savvy with this kind of stuff.
Re: [OT] Microsoft filled patent applications for scoped and immutable types
On Wednesday, 27 August 2014 at 03:00:26 UTC, Nick Sabalausky wrote: On 8/26/2014 6:52 PM, Rikki Cattermole wrote: You guys should totally move to New Zealand. Seriously you would fit right in. Best part? No software patents. Nice. I've heard that a lot of the scenery is stunning over there, too. Slow and expensive electronics importing AIUI, but maybe that'd be in my best interest anyway...biggest thing to raise my blood pressure lately was my last trip to MicroCenter[1]. Take it easy. The most important things are the ideas and the software. The latests gadgets are for users :-) As soon as I finally snap and go all luddite hermit or something, maybe that's where I'll retire ;) New Zealand that is, not MicroCenter. Swapping your chip for sheep. [1] http://www.microcenter.com/site/stores/default.aspx
Re: [OT] Microsoft filled patent applications for scoped and immutable types
On Wednesday, 27 August 2014 at 09:08:24 UTC, Chris wrote: On Tuesday, 26 August 2014 at 21:29:13 UTC, Nick Sabalausky wrote: On 8/26/2014 4:34 PM, Chris wrote: On Tuesday, 26 August 2014 at 19:37:29 UTC, Max Klyga wrote: Microsoft being microsoft again. http://www.freepatentsonline.com/y2014/0196015.html - DECLARATION OF LIFETIME OF RESOURCE REFERENCE This contains description of scoped classes, etc. http://www.freepatentsonline.com/y2014/0196008.html - IMMUTABLE OBJECT TYPES I really hope patent office will reject these applications. That's why I absolutely love MS! It's FAR more than just MS. For example, Apple's just as bad. Just look at Steve Job's undying vendetta against Google (by way of Samsung as a proxy target). Of course, the whole lot of them! I only wonder who they're trying to attack here? It must be some sort of strategy to put someone they deem dangerous off his stride. Probably the open source community and / or a competitor. I don't know the laws in the US and don't know how serious this is. It probably can't just be ignored. Is there some other big company they're trying to get at with this? Maybe they're preparing a counter strike. Yeah, IMO these patents can't be a coincidence.
Re: [OT] Microsoft filled patent applications for scoped and immutable types
On Tuesday, 26 August 2014 at 21:29:13 UTC, Nick Sabalausky wrote: On 8/26/2014 4:34 PM, Chris wrote: On Tuesday, 26 August 2014 at 19:37:29 UTC, Max Klyga wrote: Microsoft being microsoft again. http://www.freepatentsonline.com/y2014/0196015.html - DECLARATION OF LIFETIME OF RESOURCE REFERENCE This contains description of scoped classes, etc. http://www.freepatentsonline.com/y2014/0196008.html - IMMUTABLE OBJECT TYPES I really hope patent office will reject these applications. That's why I absolutely love MS! It's FAR more than just MS. For example, Apple's just as bad. Just look at Steve Job's undying vendetta against Google (by way of Samsung as a proxy target). Of course, the whole lot of them! I only wonder who they're trying to attack here? It must be some sort of strategy to put someone they deem dangerous off his stride. Probably the open source community and / or a competitor. I don't know the laws in the US and don't know how serious this is. It probably can't just be ignored. Is there some other big company they're trying to get at with this? Maybe they're preparing a counter strike.
Re: problem creating a 32-bit dll
but then does that mean the linker already link user32.lib? On Wednesday, 27 August 2014 at 05:42:06 UTC, kdmult wrote: On Tuesday, 26 August 2014 at 20:41:27 UTC, nezih wrote: Thanks! That did the trick. Btw do you have any idea about getting rid of the linker's warning message about the user32.lib? I played with the LIB env variable in several ways and I also edited sc.ini to set the LIB but no luck so far. Just remove -Luser32.lib from the command line.
Re: OT Java stuff [was Using D]
On Tuesday, 26 August 2014 at 22:07:49 UTC, Jeremy Powers via Digitalmars-d wrote: If your users are having to install things then the problem is your deployment mechanism not the JVM dependency hell system. Java deployments are actually really quite easy. Either you package a total system with all dependencies and provide entry scripts, or you use Maven Central (or increasingly BinTray) for accessing dependencies. If I need deployment mechanisms like the ones above, then there's something wrong with the language. All these crutches and patches. To set up and test a deployment mechanism takes as long as writing the program. No thank you. This is what you get with shared libraries. If you don't want to deal with dependencies, either A) ship a static-linked binary or B) cross your fingers and pray. Statically linked binaries are still the best option, if you want to make sure things will work for the user (and you don't have time for customer service). It's also a good strategy for cross-platform development, this or you have to use an approach similar to Textadept that ships everything in one package. I usually ship all the additional dlls / libs, if there are any. Relying on system wide dynamic linking is more for cases when you develop for one particular environment or when you're 90% sure that a certain library exists on most systems you develop for. The C standard library comes to mind, but even there are differences between Linux and Windows. And don't forget that, unlike Linux users, people who use Windows are usually not tech savvy in the sense that they can deal with downloading additional libraries. It all depends on the products you're developing. But for our stuff it's better to go static or ship everything. I've found the java ecosystem to be quite well fleshed out and mature in handling lib/jar dependencies, such that it was an unpleasant shock dealing with C++ after years away. Using maven, for instance, is a quick and easy way to abstract the problems away (though it is better suited for builds than deployments). As D gets more support for dynamic libraries, it would be good to take lessons from how Java and others have dealt with dependency management. Yes, only better. :-)
Re: What have I missed?
On Saturday, 9 August 2014 at 07:21:28 UTC, Era Scarecrow wrote: On Saturday, 9 August 2014 at 07:12:45 UTC, eles wrote: Things will be easier when it clicks for me i'm sure. Re-reading part of the book, a portion of it, the designs behind Git makes sense, but there's no 'ah ha!' moment, not yet. How is this going?
Re: Voting: std.logger
On Tuesday, 26 August 2014 at 19:39:26 UTC, Marco Leise wrote: Am Tue, 26 Aug 2014 18:23:30 + schrieb "Dicebot" : On Tuesday, 26 August 2014 at 15:44:19 UTC, Robert burner Schadek wrote: > BTW: Someone else mentioned it before: Logging in destructors would be a requirement for me, too. It would be a pity to have forbidden spaces for logging. I very much like the fact that use of printk() is so much ubiquitous.
Re: Before we implement SDL package format for DUB
On Wednesday, 27 August 2014 at 05:47:37 UTC, Nick Sabalausky wrote: On 8/27/2014 1:40 AM, eles wrote: On Wednesday, 27 August 2014 at 01:40:41 UTC, Nick Sabalausky wrote: On 8/26/2014 1:43 PM, eles wrote: On Tuesday, 26 August 2014 at 13:55:13 UTC, Sönke Ludwig wrote: Am 26.08.2014 15:37, schrieb eles: On Monday, 25 August 2014 at 19:35:09 UTC, Jonathan M Davis wrote: On Monday, 25 August 2014 at 18:31:42 UTC, Marc Schütz wrote: All reasonable points, but it still seems like swatting a fly with a bazooka. ;) Well, you need a sharp eye and a sure hand. But otherwise, the sole problem is if the fly is on someone's nose...
Re: Before we implement SDL package format for DUB
On Wednesday, 27 August 2014 at 02:24:46 UTC, Nick Sabalausky
wrote:
That's somewhat misleading.
More accurately, SDL is newline-delimited (with backslash line
continuation). That's pretty darn simple and has an age-old
history. It's not like we're talking weird Python/JavaScript
rules or anything here.
The only thing that does trip people up is that the existence
of { and } in the syntax makes people think "C-family and
therefore freeform". And then it isn't, so that makes them
angry. "Yeeargh! Hulk Not Want!" Well...or something vaguely
sorta kinda like that ;)
That's justified, because SDL fails to not surprise. Curly brace
syntaxes are not line-delimited not requires backslash line
continuations.
- XML is XML. I find it actually OK.
I would support this. Yes, is verbose, we know that. But is a
very solid
foundation.
XML is the spawn of satan. And not the cool "rock n roll",
"heavy metal" kind of satan, or the bumbling lovable DBZ "Mr.
'Hercule' Satan" either, but the "hey, let's write a commercial
webserver in shell scripts" kind of raw pulsating evil.
What's wrong with XML? I work with it daily and see no problem.
The less syntax a language has, the worse it scales, and if it
doesn't scale, its adoption creates a technical debt. 100 lines
with 3 levels of nesting and JSON becomes hard to follow and TOML
becomes simply unmanageable.
Re: [OT] Microsoft filled patent applications for scoped and immutable types
On 8/27/2014 12:11 AM, via Digitalmars-d wrote: On Tuesday, 26 August 2014 at 21:30:40 UTC, Brad Anderson wrote: On Tuesday, 26 August 2014 at 21:26:36 UTC, H. S. Teoh via Digitalmars-d wrote: D has had immutable for years! Surely that counts as prior art?? Does the patent office accept prior art submissions? T They do. http://meta.patents.stackexchange.com/a/107 I don't like that. Even if we want to break this patent with prior art, we need to publish one for ourselves. This system sucks, we can't choose not to be part of it if we want to be protected. And do we have the money to publish patents anyway? I feel pretty bad about this. What are the thoughts of Andrei and Walter on this stuff? In the US, filing a patent app requires about $10k and a good lawyer. It's not in the realm of most small entities to do. It's a seriously bad use of $10k. The best defense is prior art, and there's a ton of it. I say this having my name on a handful of applications and one granted patent.
Re: [OT] Microsoft filled patent applications for scoped and immutable types
On Tuesday, 26 August 2014 at 21:30:40 UTC, Brad Anderson wrote: On Tuesday, 26 August 2014 at 21:26:36 UTC, H. S. Teoh via Digitalmars-d wrote: D has had immutable for years! Surely that counts as prior art?? Does the patent office accept prior art submissions? T They do. http://meta.patents.stackexchange.com/a/107 I don't like that. Even if we want to break this patent with prior art, we need to publish one for ourselves. This system sucks, we can't choose not to be part of it if we want to be protected. And do we have the money to publish patents anyway? I feel pretty bad about this. What are the thoughts of Andrei and Walter on this stuff?
