Re: [Mono-D] v2.1.18 Parser/Completion/General fixesimprovements
On 8/13/2014 1:32 PM, Dicebot wrote: On Wednesday, 13 August 2014 at 18:13:22 UTC, simendsjo wrote: On 08/13/2014 04:16 PM, Alex wrote: (...) You should've noticed that the installation instruction stuff has been moved to the D wiki - http://wiki.dlang.org/Mono-D (...) Is it just me, or is there something very strange going on with the wiki? Seems a lot of CSS isn't applied on that page and the front page - No logo, login, edit etc etc (navigation at the bottom). Other pages looks fine though. Just my browser, or is anyone else experiencing the same issue? Can confirm. It was OK just a few hours ago though It's working fine for me using Opera, although the CSS may very well be cached for me...
Re: DConf 2013 to be livestreamed, I'll take questions during my keynote at 9 AM PST
On 5/20/2014 2:34 PM, Andrei Alexandrescu via Digitalmars-d-announce wrote: https://hn.algolia.com/#!/all/last_24h/prefix/0/dconf%202014 Andrei Also, if you prefer your IRC client over the chat client that ustream has, you can connect to it as IRC via the server chat1.ustream.tv then join the #dconf-2014 channel. To register your nick, register on ustream, then connect to the IRC with your username as your nick, and use /PASS yourPass.
Re: DConf 2013 to be livestreamed, I'll take questions during my keynote at 9 AM PST
On 5/20/2014 2:51 PM, Orvid King via Digitalmars-d-announce wrote: Also, if you prefer your IRC client over the chat client that ustream has, you can connect to it as IRC via the server chat1.ustream.tv then join the #dconf-2014 channel. To register your nick, register on ustream, then connect to the IRC with your username as your nick, and use /PASS yourPass. Unfortunately though, the IRC they use doesn't support SSL connections.
Re: Livestreaming DConf?
On Friday, 9 May 2014 at 19:48:20 UTC, Andrei Alexandrescu wrote: Hi folks, We at Facebook are very excited about the upcoming DConf 2014. In fact, so excited we're considering livestreaming the event for the benefit of the many of us who can't make it to Menlo Park, CA. Livestreaming entails additional costs so we're trying to assess the size of the online audience. Please follow up here and on twitter: https://twitter.com/D_Programming/status/464854296001933312 Thanks, Andrei Well, I'd certainly watch, I was actually intending to request that someone do this, even if it were as simple as someone with a webcam broadcasting to twitch.
Re: Bugzilla maintenance tonight
On Wed, 09 Apr 2014 07:38:14 -0500, Sönke Ludwig sludwig+dfo...@outerproduct.org wrote: Not sure what exactly needs to be done about it, but I noticed that Deskzilla Lite doesn't recognize issues.dlang.org as an open source installation and thus denies to add the D product with its 12k bugs. They've now updated the sponsored servers list, and you can now use it again with D's bugzilla.
Re: Bugzilla maintenance tonight
For the Deskzilla Lite problem, it's because the new URL isn't currently on their list of open-source project's urls. I just opened an issue (https://jira.almworks.com/browse/DZO-1187) with them about it. On 4/9/14, Brad Roberts bra...@puremagic.com wrote: On 4/9/14, 5:55 AM, Sönke Ludwig wrote: Am 09.04.2014 14:38, schrieb Sönke Ludwig: Not sure what exactly needs to be done about it, but I noticed that Deskzilla Lite doesn't recognize issues.dlang.org as an open source installation and thus denies to add the D product with its 12k bugs. Also seems like votes are disabled. Fixed, that code was moved to an extension which needed to be explicitly enabled.
Re: warp: a fast C and C++ preprocessor
On Monday, 31 March 2014 at 14:46:32 UTC, Andrei Alexandrescu wrote: It's quite obvious. The D codebase is smaller and simpler than clang pp's and can be taken many places; the next thing I'll work on is multithreaded preprocessing that shares already opened files. One thing that is self-evident but the article could have stressed is that open-sourcing warp is the beginning, not the end of its lifecycle. There's a lot of improvements that are within easy reach for warp, and are easier to realize than for clang. Andrei We also have the ability to present it in a different use-case, pre-processing every header in one invocation, allowing warp to do some optimizations that Clang and GCC won't do, such as unconditional pre-processing (stripping comments and things such as #if 0 / #if 1, or conditions that are unconditionally met by things defined within the header, typically used to disable/enable certain code) because they would be of very limited use to GCC and Clang, which are typically invoked once for every source file. Warp could also offer the ability to pass certain #define's that are known to never be #undef'd by the source code (such as compiler capabilities / version identifications), allowing for more extensive unconditional pre-processing.
Re: std.serialization
What features does it support? How does it handle: * Arrays * Slices * Pointers * Reference types * Support for events * Custom serialization * Serialization of third party types Slices are handled as arrays, because of the fact that they need to be handled in such a way that many different types of serialization formats can support them, and be inter-operable with implementations in languages other than D. Pointers are not supported, because in my opinion, they should _NEVER_ be serialized. Reference types are serialized as they are encountered, I haven't handled the circular reference case yet. Events are not supported due to the fact it would require complete knowledge of the source and target environments of the serialization. Custom serialization is supported by either supporting to!YourType(string) or YourType.parse(string) / to!string(valueOfYourType) or valueOfYourType.toString(), and are handled transparently by the base serialization handler, the actual serialization format sees them simply as strings. Each serialization format however does have the ability to select any type it wants to support being serialized. And third party types are only supported if they have the requisite UDA, or support custom serialization. Why require a UDA? The UDA is required for the exact same reason it's required in the .net framework, because it makes sure that the type you are trying to serialize is serialization aware, meaning that it's not serializing cache fields, and also makes sense to actually be serializing the type.
Re: std.serialization
I already have all this in Orange [1], which I'm in progress of adapting to a package for Phobos. ... This requires registering the subclass in some way. In my implementation one needs to call: Serializer.register!(Sub); For full example see [2]. [1] https://github.com/jacob-carlborg/orange [2] https://github.com/jacob-carlborg/orange/wiki/Base-Class The problem with the way your doing it though is that it requires that the library doing the deserialization is fully aware of the semantics used in the serialization implementation, rather than just the syntax and semantics of the selected serialization format.
Re: std.serialization
Why not? Think of languages like C and C++, they only support pointers.
Pointers to basic types are not so interesting but pointers to structs
are.
Because, by serializing a pointer, you are implying that mechanism that
will be deserializing the value both exists on the same machine, and lies
within the same address space, otherwise it will be referencing incorrect
data.
If the same reference value is encountered multiple times, is it
serialized once or multiple times?
It is currently serialized multiple times. Serializing once would require
a mechanism to exist on both the serializer and deserializer that
understands and can interpret those references. As there is not a standard
mechanism in JSON to support this, I haven't actually gotten around to
implementing that.
What? I'm referring to methods being called before and after
serialization of a given value.
Woops, that means I simply mis-understood your question. The answer to
your actual question is somewhat, there is a single code path for dynamic
types, I've only implemented support in a modified version of
Destructionator's JSVar library, but it should be possible to add support
to Variant without any real issue, that does support javascript's 2
parameter json serialization, there are not however callbacks for the
start and end of serialization.
I prefer opt-out rather than opt-in.
Well, if I ever get around to cleaning up the codebase enough to submit it
for inclusion in Phobos, there can be a nice long discussion about the
pro's and con's of each, because it's a very simple check to remove.
Can it serialize through base class references?
It currently retrieves all fields present in the class heirarchy, so if
you have classes A, B, and C defined as follows:
class A
{
@optional
int aA = 10;
}
class B : A
{
@serializeAs(Bob)
int bob;
}
class C : B
{
int cA;
@nonSerialized
int cB;
}
Then calling toJSON on an instance of class C, and have modified the value
of aA, it will produce a result containing fields defined as aA, Bob, and
cA.
Because cB is marked as @nonSerialized, it is ignored during serialization.
Next, bob is serialized as Bob because it is marked as @serializeAs which
is intended to account for the difference in naming conventions between
different languages, in this case the source of the serialized data may
very well be C#, where the convention is typically PascalCase. We however
are programming in D, where, if you're me at least, you use camelCase for
fields.
Lastly, if we hadn't modified the value of aA, and it was still 10, it
would not be included in serialization results, because it is marked as
@optional, and contains the same value it would were it default
constructed.
Re: std.serialization
On Friday, 14 February 2014 at 11:22:22 UTC, Daniel Murphy wrote: Orvid King wrote in message news:ntpjdeutsxqicjywt...@forum.dlang.org... (except for float-string conversion, which I don't understand the algorithms enough to implement myself) even going so far as to create an output range based version of to!string(int/uint/long/ulong/etc.). std.format.formatValue / std.format.formattedWrite ? Both of them fall back on a form of printf internally.
Re: std.serialization
On Friday, 14 February 2014 at 10:41:54 UTC, Francesco Cattoglio wrote: On Thursday, 13 February 2014 at 22:56:38 UTC, Orvid King wrote: so I'm releasing it as std.serialization. What does that even mean? I'm pretty sure you should NEVER call a library std.something if it hasn't been approved for inclusion into standard library. Other than that, nice work. Yes, well, I'm bad at coming up with creative names, and, once I get around to writing full documentation for it, as well as do a bit of other cleanup, I'll submit it for inclusion in Phobos.
std.serialization
Well, I wrote the code for this a while back, and although it was originally intended as a replacement for just std.json (thus the repo name), it does have the framework in place to be a generalized serialization framework, and there is the start of xml, and bson implementations, so I'm releasing it as std.serialization. The JSON implementation is the only one I'd consider ready for production use however. The (de)serialization framework takes a step back and asks, Why do we need pull parsers?, the answer to which is that allocations are slow, so don't allocate. And that's exactly what I do. The serializer does absolutely *no* allocations of it's own (except for float-string conversion, which I don't understand the algorithms enough to implement myself) even going so far as to create an output range based version of to!string(int/uint/long/ulong/etc.). And the benefits of doing it this way are very clearly reflected in the pure speed of the serializer. On my 2ghz i5 Macbook Air, it takes 50ms to serialize 100k objects with roughly 600k integers contained in them when compiled with DMD, this roughly half the time it takes to generate the data to serialize. Compile it with GDC or LDC and that time is cut in half. I have done the exact same thing with deserialization as well, the only allocations done are for the output objects, because there is no intermediate representation. So how do I use this greatness? Simple! import std.serialization, and apply the @serializable UDA to the class/struct you want to serialize, then call toJOSN(yourObject) and fromJSON!YourType(yourString) to your heart's content! Now, there are other serialization libraries out there, such as orange, that take the compile-time reflection approach, but the amount of code required to implement a single format is just massive 2100 lines for the XMLArchive. The entire JSON (de)serialization, which *includes* both the lexer and parser is only 900 lines. Wow, that went a bit more towards a salesman-like description than I as aiming for, so I'll just end this here and give you the link, before this ends up looking like a massive, badly written, sales pitch :D https://github.com/Orvid/JSONSerialization
Re: dmd 2.064.2
On Tuesday, 5 November 2013 at 22:08:48 UTC, Walter Bright wrote: Ok, this is it: http://ftp.digitalmars.com/dmd_2.064.2-0_amd64.deb http://ftp.digitalmars.com/dmd-2.064.2-0.fedora.i386.rpm http://ftp.digitalmars.com/dmd-2.064.2-0.fedora.x86_64.rpm http://ftp.digitalmars.com/dmd_2.064.2-0_i386.deb http://ftp.digitalmars.com/dmd-2.064.2-0.openSUSE.i386.rpm http://ftp.digitalmars.com/dmd-2.064.2-0.openSUSE.x86_64.rpm http://ftp.digitalmars.com/dmd-2.064.2.exe http://ftp.digitalmars.com/dmd.2.064.2.zip http://ftp.digitalmars.com/dmd.2.064.2.dmg http://ftp.digitalmars.com/libphobos2-64_2.064.2-0_amd64.deb http://ftp.digitalmars.com/libphobos2-64_2.064.2-0_i386.deb Dear world: DO NOT use the windows installer if you have ANYTHING other than the default installed files in your previous install folder, because it will delete EVERYTHING. (and this isn't an understatement, my C:/D folder is now entirely empty but for a single git index which was locked by my IDE), this means I have now lost my local checkouts of the D repos, my git-head dmd install location, as well as my auto-build-install-test scripts, and my local copy of my JSON work. Thankfully my JSON work wasn't even the latest copy anyways. Deleting everything IS NOT uninstalling.
