February 10, 2007
janderson wrote:
> Andrei Alexandrescu (See Website For Email) wrote:
>> janderson wrote:
>>> Yauheni Akhotnikau wrote:
>>>> On Thu, 08 Feb 2007 10:08:29 +0300, Walter Bright <newshound@digitalmars.com> wrote:
>>>>
>>
>> Probably an easier way to go would be:
>>
>> class A
>> {
>>   ...
>>   int x;
>>   B y;
>>   int z;
>> }
>>
>> mixin(serialize!(A, "x=10, y"));
> 
> I'm not sure I'd need a mixin for this.

Oh, indeed. A template instantiation is all that's needed. (It would use mixins inside for parsing the spec string.)


Andrei
February 10, 2007
On Sat, 10 Feb 2007 03:14:48 +0300, Andrei Alexandrescu (See Website For Email) <SeeWebsiteForEmail@erdani.org> wrote:

> Probably an easier way to go would be:
>
> class A
> {
>    ...
>    int x;
>    B y;
>    int z;
> }
>
> mixin(serialize!(A, "x=10, y"));
>
> This way you leave to the compiler the task of parsing the class, and you only deal with the annotations.

Yes. And this has yet another advantage -- it may be necessary to support several servialization methods at one time. For example, home-made serialization method and ASN.1 BER serialization:

// home-made serialization.
mixin( serialize!(A, "x=10, y"));
// ASN.1 BER.
mixin( asn1ber_serialize!(A, "x,tag=0x1020,optional=10", "y,tag=0x1139"));

-- 
Regards,
Yauheni Akhotnikau
February 10, 2007
On 2007-02-06 23:51:17 -0800, "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail@erdani.org> said:

> Vladimir Panteleev wrote:
>> On Tue, 06 Feb 2007 06:54:18 +0200, Walter Bright <newshound@digitalmars.com> wrote:
>> 
>>> http://www.digitalmars.com/d/changelog.html
>> 
>> Hmm. What would prevent someone from writing programs like:
>>    writef(import("/etc/passwd"));
>> and trick someone to compile this program for them (under the pretext that they don't have a D compiler, for example) to steal the user list (or the contents of any other file with a known absolute or relative path on the victim's system)?
>> 
>> IMO, the compiler should at least issue a warning when importing a file not located in/under the source file's directory. Although, if the source emits a lot of pragma(msg) messages, the warning might get cluttered by those - or this might be concealed in a large program with a lot of files. A better security-wise solution is to disallow importing files outside the source file's directory, unless specified by the user on the command-line.
> 
> How would the bad person see the output of the compilation?
> 
> Andrei


By asking someone else to compile code for you and send back the executable.  Some services exist for compiling C/C++ on the web and this concern would prevent people from doing the same with D.

-- Jeff McGlynn

February 10, 2007
Jeff McGlynn wrote:
> On 2007-02-06 23:51:17 -0800, "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail@erdani.org> said:
> 
>> Vladimir Panteleev wrote:
>>> On Tue, 06 Feb 2007 06:54:18 +0200, Walter Bright <newshound@digitalmars.com> wrote:
>>>
>>>> http://www.digitalmars.com/d/changelog.html
>>>
>>> Hmm. What would prevent someone from writing programs like:
>>>    writef(import("/etc/passwd"));
>>> and trick someone to compile this program for them (under the pretext that they don't have a D compiler, for example) to steal the user list (or the contents of any other file with a known absolute or relative path on the victim's system)?
>>>
>>> IMO, the compiler should at least issue a warning when importing a file not located in/under the source file's directory. Although, if the source emits a lot of pragma(msg) messages, the warning might get cluttered by those - or this might be concealed in a large program with a lot of files. A better security-wise solution is to disallow importing files outside the source file's directory, unless specified by the user on the command-line.
>>
>> How would the bad person see the output of the compilation?
>>
>> Andrei
> 
> 
> By asking someone else to compile code for you and send back the executable.  Some services exist for compiling C/C++ on the web and this concern would prevent people from doing the same with D.

I see. This is a new scenario indeed. Given previous experience with TeX, it looks like the compiler switch approach could take care of it.

Andrei
February 11, 2007
Andrei Alexandrescu (See Website For Email) wrote:
> Jeff McGlynn wrote:
>> By asking someone else to compile code for you and send back the executable.  Some services exist for compiling C/C++ on the web and this concern would prevent people from doing the same with D.
> 
> I see. This is a new scenario indeed. Given previous experience with TeX, it looks like the compiler switch approach could take care of it.

The switch will be in the next update.

C/C++ doesn't really have this problem with #include, since that will only read files that consist of preprocessor tokens. Arbitrary files will not work.
February 11, 2007
Charles D Hixson wrote:
> Were I to select a Forth to use I'm probably pick gforth or bigforth (+ Minos?).

IMHO the tool (=programming language) should be chosen according to the work at hand, and to the mastership one can achieve as an individual with a certain tool. For some people FICL is a good tool
http://ficl.sourceforge.net/

It should not be too difficult to incorporate it into D applications as _resident_ interactive debugging aid _during_runtime_.

> Neon, though, was impressive.  I think there's a version calls MOPS or mops or some such still extant, but I don't know how complete it is, and last I checked it only ran on Mac pre-OSX.  (I trust that's no longer true...if not, it's history.)

See
http://powermops.sourceforge.net/index.php/Main_Page
February 11, 2007
Andreas Kochenburger wrote:
> Charles D Hixson wrote:
>> Were I to select a Forth to use I'm probably pick gforth or bigforth (+ Minos?).
> 
> IMHO the tool (=programming language) should be chosen according to the work at hand, and to the mastership one can achieve as an individual with a certain tool. For some people FICL is a good tool
> http://ficl.sourceforge.net/
> 
> It should not be too difficult to incorporate it into D applications as _resident_ interactive debugging aid _during_runtime_.
> 
>> Neon, though, was impressive.  I think there's a version calls MOPS or mops or some such still extant, but I don't know how complete it is, and last I checked it only ran on Mac pre-OSX.  (I trust that's no longer true...if not, it's history.)
> 
> See
> http://powermops.sourceforge.net/index.php/Main_Page

Glad to hear it's still going... sorry to hear it's soon to be gone.  (The author announces no plans to port to the Intel Macs...well, he's a bit stronger about it than that.)
February 11, 2007
Jarrett Billingsley wrote:
> "Jarrett Billingsley" <kb3ctd2@yahoo.com> wrote in message news:eqcmo3$2u17$1@digitaldaemon.com...
> 
> Just wanted to add that something I find severely lacking is that there's no way to get a pretty (usable, non-mangled) string representation of a type. Instead we have to write large template libraries to accomplish something that the compiler does _all the time_.  This means it's currently not possible to do something like
> 
> template MakeVariable(Type, char[] name)
> {
>     const char[] MakeVariable = Type.nameof ~ " " ~ name ~ ";";
> }
> 
> mixin(MakeVariable!(int, "x"));
> 
> Instead we have to use a template library to demangle the name:
> 
> import ddl.meta.nameof;
> 
> template MakeVariable(Type, char[] name)
> {
>     const char[] MakeVariable = prettytypeof!(Type) ~ " " ~ name ~ ";";
> }
> 
> mixin(MakeVariable!(int, "x"));
> 
> 
> :\ 
> 
> 

Well, actually you can do that, with the unannounced (in the changelog) .stringof property ( http://www.digitalmars.com/d/property.html ) :

----

template MakeVariable(Type, char[] name)
{
  const char[] MakeVariable = Type.stringof ~ " " ~ name ~ ";";
}

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
February 11, 2007
Bruno Medeiros wrote:
> Well, actually you can do that, with the unannounced (in the changelog) .stringof property ( http://www.digitalmars.com/d/property.html ) :
> 
> ----
> 
> template MakeVariable(Type, char[] name)
> {
>   const char[] MakeVariable = Type.stringof ~ " " ~ name ~ ";";
> }

It's unannounced because it doesn't work right yet.
February 12, 2007
Walter Bright wrote:
> Bruno Medeiros wrote:
>> Well, actually you can do that, with the unannounced (in the changelog) .stringof property ( http://www.digitalmars.com/d/property.html ) :
>>
>> ----
>>
>> template MakeVariable(Type, char[] name)
>> {
>>   const char[] MakeVariable = Type.stringof ~ " " ~ name ~ ";";
>> }
> 
> It's unannounced because it doesn't work right yet.

What do you mean? If it's doesn't work right yet, why was it released already? (basic cases seem to be working)

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D