Greetings,

I'd like to extract the command-line arguments passed to a DMDScript script.
For example, if I enter the following command:

   ds myscript.ds 1 "aaa" DMD

I would like the values:

   1
   aaa
   DMD

to be accessable from within the script.

I am able to accomplish this task via the Windows Scripting Host using the
following code:

   // Extract command-line arguments, and load into
   // 'arguments' array
   if (WScript.Arguments.length < 1)
   {
     arguments = new Array(0);
   }
   else
   {
     arguments = new Array(WScript.Arguments.length);

     for (var i = 0 ; i < arguments.length; ++i)
       arguments[i] = WScript.Arguments(i);
   }

   // Display command-line arguments
   for (var i = 0 ; i < arguments.length; ++i)
     WScript.Echo("Argument[" + i + "] is " + arguments[i]);

Using DMDScript, the 'println' function is the obvious analog of
'WScript.Echo'. However, I'm not aware of a global array, or function, of
similar functionality to, 'WScript.Arguments'.

So my questions are:

* Is there such an array or function natively available in
  DMDScript ?

* If not, is it possible to perhaps 'hook into' a D function
  with this functionality *without* having to modify the
  DMDScript source code, and recompile the interpreter ?

* If not, are there plans add such functionality to future
  versions of DMDScript ?

I look forward to any response.

Cheers,

Anthony Borla

Anthony Borla escribió:
> Greetings,
> 
> I'd like to extract the command-line arguments passed to a DMDScript script.
> For example, if I enter the following command:
> 
>     ds myscript.ds 1 "aaa" DMD
> 
> I would like the values:
> 
>     1
>     aaa
>     DMD
> 
> to be accessable from within the script.
> 
> I am able to accomplish this task via the Windows Scripting Host using the
> following code:
> 
>     // Extract command-line arguments, and load into
>     // 'arguments' array
>     if (WScript.Arguments.length < 1)
>     {
>       arguments = new Array(0);
>     }
>     else
>     {
>       arguments = new Array(WScript.Arguments.length);
> 
>       for (var i = 0 ; i < arguments.length; ++i)
>         arguments[i] = WScript.Arguments(i);
>     }
> 
>     // Display command-line arguments
>     for (var i = 0 ; i < arguments.length; ++i)
>       WScript.Echo("Argument[" + i + "] is " + arguments[i]);
> 
> Using DMDScript, the 'println' function is the obvious analog of
> 'WScript.Echo'. However, I'm not aware of a global array, or function, of
> similar functionality to, 'WScript.Arguments'.
> 
> So my questions are:
> 
> * Is there such an array or function natively available in
>    DMDScript ?
> 
> * If not, is it possible to perhaps 'hook into' a D function
>    with this functionality *without* having to modify the
>    DMDScript source code, and recompile the interpreter ?
> 
> * If not, are there plans add such functionality to future
>    versions of DMDScript ?
> 
> I look forward to any response.
> 
> Cheers,
> 
> Anthony Borla
> 
> 

DMDScript treats its command line arguments rather oddly, but there's a global 
variable "arguments". There're two paths you can take: modify DMDScript source 
(maybe testscript.d would be enough) so command line arguments are not treated 
as more source files and then pass them to the program, or use Walnut, which 
already does that for you. The problem with Walnut is that it's kinda on 
extended hold by now because I'm busy with other things, but I think there's a 
compiled version available for Windows on www.dsource.org which you can use (I'm 
not telling you to compile it because I doubt it'll compile.)

-- 
Carlos Santander Bernal

"Carlos Santander" <csantander619@gmail.com> wrote in message
news:dk6lfb$26pr$1@digitaldaemon.com...
> Anthony Borla escribió:
> > Greetings,
> >

Carlos,

> >
> > I'd like to extract the command-line arguments passed
> > to a DMDScript script. For example, if I enter the
> > following command:
> >
<SNIP>
>
> DMDScript treats its command line arguments rather
> oddly, but there's a global variable "arguments".
>

That was the first thing I tried. Yes, a global 'arguments' exists, but
command-line values do not get passed to them. For example, issuing from the
command-line:

   ds myscript.ds X Y Z

should see the following occur in the script:

   ...
   println(arguments[0]);  // X printed
   println(arguments[1]);  // Y printed
   println(arguments[2]);  // Z printed
   ...

Instead the observed behaviour is:

   ...
   println(arguments[0]);  // undefined
   println(arguments[1]);  // "
   println(arguments[2]);  // "
   ...

and DMDScript interprets the first command-line argument as a file name:

   Error: X.ds: The system cannot find the file specified.

This is unintuitive behaviour for a command-line tool whether executed in a
Windows-family, or a *NIX environment.

>
> There're two paths you can take: modify DMDScript
> source (maybe testscript.d would be enough) so
> command line arguments are not treated as more
> source files and then pass them to the program,
>

Yes, I *could* modify the source code and add the requisite behaviour
[including remedying the other behavioural 'anomolies' mentioned in my other
posts].

However, not being a D expert, it would take a significant amount of my
time. To be quite honest, if I'd wanted to write D code, I'd do so, and not
bother using an ECMAScript interpreter :) ! In addition, any enhancements
would only be of benefit to users of this customised version of the
interpreter rather than to all those future downloaders of DMScript from the
DigitalMars website. Rather a waste of effort I should think !

>
> or use Walnut, which already does that for you. The problem
> with Walnut is that it's kinda on extended hold by now because
> I'm busy with other things, but I think there's a compiled version
> available for Windows on www.dsource.org which you can use
> (I'm not telling you to compile it because I doubt it'll compile.)
>

I truly do appreciate your suggestion because you are making a constructive
suggestion to help me solve a specific problem. However, I'm not sure that
using yet another tool to remedy a 'problem' in an existing tool is the
answer [IMO it does not adhere to the KISS principle].

What I'd really like to see for my, and I'm sure, many other people's
benefit, is a revised version of DMDScript which remedies the 'problems' I
mentioned here, and in related posts. My argument for suggesting this is as
follows.

Whilst DMDScript is presented as both a 'showcase' product for the D
language, and as an embeddable ECMAScript interpreter [both roles, I
believe, it admirably fulfils], it is also presented in a command-line
version, presumably to act as a 'command-line tool'. Sadly, owing a number
of minor, but behaviourally significant, deficiencies, it does not
effectively fulfil this role. For example, I can't use it in my script files
[I have to, instead, use WSH 5.6] because it can neither accept command-line
arguments, return an exit code, nor correctly read text files. I'm sure I'm
not the only one hampered by such difficulties.

Sadly, this serves only to limit DMDScript's potential user base. Further,
it may even leave others with a poor, or negative, opinion of the product.
It seems a shame to tarnish the reputation of an otherwise fine product by
not applying a few 'finishing touches' to it.

Finally, I'm not being critical just for the sake of it. If I was in a
position to make the requisite improvements I would have done so [I much
prefer action to words, but this isn't always possible]. I would have
thought, though, that in the four months since I first mentioned these
problems, that some action by the relevant experts would have been taken.

Cheers,

Anthony Borla

P.S.

The version I've been using is:

   Digital Mars DMDScript 1.06
   www.digitalmars.com
   Compiled by Digital Mars DMD D compiler
   Copyright (c) 1999-2005 by Digital Mars
   written by Walter Bright

which I believe is the latest.

Wow.

Thanks for the heads up Anthony.  I've got to go do a friend's website today,
but tommorrow I'll work on implementing (at least) one of your changes.

I actually noticed a few of the same problems.  :p  Needless to say, I thought
DMDScript was a little more capable as well.  My understanding is though that
it, at one point, did support command line arguments (it seems to be just
choking on the first one?)

This may also explain why it doesn't accept piped input too.  :p  I haven't done
any real homework into how piping text around works.  (call myself a programmer,
gawd)

"Dan" <Dan_member@pathlink.com> wrote in message
news:dk9bd0$1l4d$1@digitaldaemon.com...
>

Dan,

>
> Wow.
>
> Thanks for the heads up Anthony.  I've got to go do a friend's
> website today, but tommorrow I'll work on implementing
> (at least) one of your changes.
>
> I actually noticed a few of the same problems.  :p  Needless
> to say, I thought DMDScript was a little more capable as well.
>

It *is* definitely capable [e.g. exception handling works fine whilst it
doesn't do so in WSH 5.6], and is *fast*, but it just has a few command-line
operation-oriented 'glitches' which, I think, are crying out to be remedied.

To recap, the important ones are:

* Command-line argument processing; probably best
  to properly fill the global 'arguments' object so that:

      arguments[0]   // ==> 1st argument
      arguments[1]   // ==> 2nd argument

  and so on

* An 'exit' function to return an arbitrary integer value to
  the OS

* Fix 'readln' so it distinguishes between an 'empty' line
  and EOF. I'd imagine the easiest approach would be
  to have 'null' returned on EOF, and a zero-length string
  for 'empty' lines [since it 'eats' the line terminator]

With these in place it should be possible to, quite effectively, use
DMDScript for command-line scripting such as, for example, creating filters.

Optionally, I suppose, file-oriented I/O could be expanded:

* 'open', 'close' functions, returning / taking a file
   handle / descriptor etc

* Extend 'readln' to accept a file handle / descriptor
  so that an arbitrary file can be read [same with 'print' and
  'println', for output]

but this would obviously be for another time.

>
> My understanding is though that it, at one point, did support
> command line arguments (it seems to be just choking on the
> first one?)
>

I honestly don't know the history. I downloaded DMDScript 1.6 a few months
ago hoping to use it in my scripts [both Windows 'batch' and *NIX 'bash'
scripts] but the problems I mentioned pretty well hampered those efforts.

>
> This may also explain why it doesn't accept piped input
> too.  :p
>

Yes, another command-line operation-oriented glitch. This would, I'd
imagine, come under the task of getting 'readln' to work correctly.

>
> I haven't done any real homework into how piping
> text around works.
>

No need to know everything, just enough to allow the job at hand to be
completed.

>
>  (call myself a programmer, gawd)
>

So do I. However these days I avoid compiled / statically-typed languages
like the plague [only digging such tools out when I absolutely have to], and
will continue to do so for as long as I am able.

Cheers,

Anthony Borla

P.S.

I can't really help with programming tasks [these, I find, are *always* very
time-consuming even when they are - supposedly - minor or simple], but am
more than happy to help in testing, and related matters.

With any luck, a DMDScript version 1.6x will soon be a reality :) !

Phhhh...

I just spent the whole week working on my new Asma library.  It is a macro
library that allows HLL programming in NASM, including explicit
STD/Pascal/C/Fastcall declaration AND calls, local variables (managed
differently by calling method), switches, loops, if/else/elseif/endif, multiple
push/pops and stuff like that.

It goes very nicely with my new assembly Array function library (that
interestingly has most of the same functionality as the ECMAScript Array object
with the JavaScript 1.6 extensions)

I did not, however, do any work on my modified DMDScript engine.  At this point,
I'm thinking it's about time I publish that... :p  I'll post back when I've done
that.

Okay, here is a link to a fuuuugly page where you can get the code I've done so
far.  So far, all I've done is run it through my home-brewed DTidy.js script,
which atm is only slightly better than your average tidier upper.  It also does
some neat stuff with cleaning up branching logic.

Some obvious bugfixes need to be done, as was said earlier.

Also, it's obvious that there would be some performance/codesize improvements to
be gained from unifying errmsgs.d and text.d (and use constants instead of array
offsets + enums).  I was working on making textgen handle both, but I started
working on Asma before I was done.

The other biggie I noticed is that DMDScript uses *cough*crap*cough* like malloc
and memset to do stuff.  Fugly.  For most of those routines, they could be
rewritten in 'bout 20 lines of asm for a 10-100% boost in performance.  That's
before I even touch the ECMAScript method implementations.

So DMDScript is ~sexy~ but, I think a dedicated hacker could easily pull another
200% time complexity out of it without getting his hands dirty.

EEP.. so the fugly page is at:

http://code.murpsoft.com/dmdScript/index.asp

"Dan" <Dan_member@pathlink.com> wrote in message
news:dkj4qu$26nu$1@digitaldaemon.com...
>

Dan,

>
> EEP.. so the fugly page is at:
>
> http://code.murpsoft.com/dmdScript/index.asp
>

Sorry for the delay in looking at this [got caught up at work], but will do
so this weekend.

Cheers,

Anthony Borla

In DMDScript, the Global object is creating an array called arguments (I saw
some things about it in the source).  I tested it out and for some stupid reason
or another in Windows (at least) it's claiming that arguments is undefined.

Perhaps the symbol is not being linked to the array, perhaps something is
buggered or perhaps I misunderstood.  I'll work on this tonight.

My test script:

for(var i = arguments.length-1; i--;){
println(arguments[i]);
}

This currently loops infinitely btw.  :p
Wish me luck!