OS string (uname)

[Christoph Dorn]

How would I get the OS string (uname)?

require("system").os does not work.

Christoph

[Jeff Johnson]

On Sep 21, 2011, at 12:16 PM, Christoph Dorn wrote:

> How would I get the OS string (uname)?
>
> require("system").os does not work.
>

Doesn't work for likely the same reason that O_TRUNC doesn't wor.

The names in the structure returned by uname(2) are accessed
with -lffi wrappings.

If the auto generated JS goes AWOL, then the methods break.

73 de Jeff

[Christoph Dorn]

But we fixed that last night.

require("fs-base") methods now work for me.

Christoph

[Wes Garland]

Is require("system").os part of the ratified spec?  If so we'll need to upgrade GPSEE at some point.

At any rate, this should work for you:

const ffi = require("gffi");
const { int, pointer, CFunction, MutableStruct } = ffi;

const uname    = new CFunction(int, "uname", pointer);
const strerror = new CFunction(pointer, "strerror", int);

require("system").__defineGetter__("os", function()
{
  var name = new MutableStruct("struct utsname");

  if (uname(name) == -1)
    throw new Error("Cannot determine OS name (" + strerror(ffi.errno).asString() + ")");

  return name.sysname.asString();
});

Wes

--
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102

[Jeff Johnson]

On Sep 21, 2011, at 2:06 PM, Wes Garland wrote:

Is require("system").os part of the ratified spec?  If so we'll need to upgrade GPSEE at some point.

At any rate, this should work for you:

const ffi = require("gffi");
const { int, pointer, CFunction, MutableStruct } = ffi;

const uname    = new CFunction(int, "uname", pointer);
const strerror = new CFunction(pointer, "strerror", int);

require("system").__defineGetter__("os", function()
{
  var name = new MutableStruct("struct utsname");

  if (uname(name) == -1)
    throw new Error("Cannot determine OS name (" + strerror(ffi.errno).asString() + ")");

  return name.sysname.asString();
});

Ah that would explain: a missing module prerequiste load.

Q: what is CommonJS doing about module dependencies? How reliable?

is what I'm really asking: "dependency hell" is an occupational hazard.

(aside)

I'm gonna trademark "dependency hell" so that I can look Debian devel's

and RPM lusers straight in the eye and say with a poker face:

The term "dependency hell" is tradmarked by "Wraptastic LLC" and

approate symbols MUST be used.

And then I'm gonna run like hell for safety … ;-) 

73 de Jeff

[Christoph Dorn]

Jeff Johnson wrote:
>
> On Sep 21, 2011, at 2:06 PM, Wes Garland wrote:
>
>> Is require("system").os part of the ratified spec? If so we'll need
>> to upgrade GPSEE at some point.

No. But I think it would be a good idea.

> Q: what is CommonJS doing about module dependencies? How reliable?
> is what I'm really asking: "dependency hell" is an occupational hazard.

That is my focus. No dependency hell if using CommonJS Mappings [1] as
implemented in the PINF loader. It is 100% deterministic and you have
exact control of all packages and versions that your program uses.

See: https://github.com/cadorn/ace-extjs (package.json, program.json and
program.packages.json)

Christoph

[1] - http://wiki.commonjs.org/wiki/Packages/Mappings/C

[Wes Garland]

On 21 September 2011 14:22, Jeff Johnson <n3...@mac.com> wrote:

Q: what is CommonJS doing about module dependencies? How reliable?

is what I'm really asking: "dependency hell" is an occupational hazard.

The current state of Modules/1.1.1 says that module A depends on module B only if and only when module A invokes require(B).

Upon first invocation, if B cannot be resolved, the require call must throw an exception.  It is not defined whether it is allowed to succeed on a subsequent call.

In Modules/2.0-draft8, which is not an official standard, module dependencies are declared along with the module. Web-browser based module loaders will resolve the dependencies (but not initialize the module) before the application starts, to avoid blocking calls.  The behaviour in /1.1.1 is also permitted.  It is allowable, but not required, for a Modules/2.0-draft8 system to resolve a module which was not explicitly named in the module dependencies. 
 

I'm gonna trademark "dependency hell" so that I can look Debian devel's

and RPM lusers straight in the eye and say with a poker face:

The term "dependency hell" is tradmarked by "Wraptastic LLC" and

approate symbols MUST be used.

And then I'm gonna run like hell for safety … ;-) 

HA!

BTW, dependency hell is more likely - I think - to happen between packages than between modules.  Packages are collections of modules.  In this context, modules tend to be more like C programs and object files, whereas packages tend to be more like solibs.  GPSEE does not support packages natively, but Christoph's PINF loader adds that capability.
 

Wes

[Jeff Johnson]

On Sep 21, 2011, at 2:47 PM, Wes Garland wrote:

On 21 September 2011 14:22, Jeff Johnson <n3...@mac.com> wrote:

Q: what is CommonJS doing about module dependencies? How reliable?

is what I'm really asking: "dependency hell" is an occupational hazard.

The current state of Modules/1.1.1 says that module A depends on module B only if and only when module A invokes require(B).

And so delayed and run-time and dependent and "soft" dependency like perl.

Here's a couple of thoughts for ways to avoid "dependency hell".

1) even if you wish to delay the loading and resource consumption until

actually needed, adding a "hard" dependency mode where dependencies

are registered early at one point in time (but marked unneeded or something)

likely helps QA and more. Its tricky QA with "soft" lazily loaded depndency chains,

some KISS functionality (I'd do --enable-hard-deps or similar) helps build

mommas doing distro QA.

Upon first invocation, if B cannot be resolved, the require call must throw an exception.  It is not defined whether it is allowed to succeed on a subsequent call.

Everyone gotta be doing the exceptions, sigh. But with an early/hard dependency registration

you might be able to displatya reasonable error message etc in the exception handler

(and perhaps warn early if no resolution seems viable even though you MUST

evaluate later at specific instance in time for "soft" deps. There's also the possibility

of greedy/asynchronous downloading (not that JS modules/packages will ever be 100's

Mb's but its a nice touch anyways).

In Modules/2.0-draft8, which is not an official standard, module dependencies are declared along with the module. Web-browser based module loaders will resolve the dependencies (but not initialize the module) before the application starts, to avoid blocking calls.  The behaviour in /1.1.1 is also permitted.  It is allowable, but not required, for a Modules/2.0-draft8 system to resolve a module which was not explicitly named in the module dependencies. 
 

Good: Modules 2.0 starts to sound what I've just described.

The other thing to start think about is a way to automate the dependency chains

without the need for specific overloading of requires("foo") as also

a dependency marker.

I point you at

/bin/bash --rpm-requires foo.sh

which basically drills into the shell parser (because writing a separate shell parser

is a hugely complex task) and finds every occurence of

tokens in an executable context and emits those, but doesn't execute anything whatsoever.

What I'm suggesting is something similar for gar(1): a means to parse *.js

and pull out every token that indicates an external need: even if all your

are doing si applying a pattern to pull "foo" out of

…requires("foo") …

its useful (imho) to be able to extract all script pre-requisites efficiently.

You may already be able to do this in GPSEE in JS without any fuss or muss.

bash was a huge pita largely because there is no flag to parse a

shell script and say:

Show me everything that this script needs to run successfully but don't

actually do anything at all.

I'm gonna trademark "dependency hell" so that I can look Debian devel's

and RPM lusers straight in the eye and say with a poker face:

The term "dependency hell" is tradmarked by "Wraptastic LLC" and

approate symbols MUST be used.

And then I'm gonna run like hell for safety … ;-) 

HA!

BTW, dependency hell is more likely - I think - to happen between packages than between modules.  Packages are collections of modules.  In this context, modules tend to be more like C programs and object files, whereas packages tend to be more like solibs.  GPSEE does not support packages natively, but Christoph's PINF loader adds that capability.
 

Oooh, nice, noted.

I'll have to stare at what CommonJS wishes as package markup and think: yes I've

looked, its a bit naive and flimsy for my taste atm (but packaging is a prfessional hazard

her, RPM is known to cause insanity, me included).

[Christoph Dorn]

Jeff Johnson wrote:

On Sep 21, 2011, at 2:47 PM, Wes Garland wrote:

On 21 September 2011 14:22, Jeff Johnson <n3...@mac.com> wrote:

Q: what is CommonJS doing about module dependencies? How reliable?

is what I'm really asking: "dependency hell" is an occupational hazard.

The current state of Modules/1.1.1 says that module A depends on module B only if and only when module A invokes require(B).

And so delayed and run-time and dependent and "soft" dependency like perl.

Here's a couple of thoughts for ways to avoid "dependency hell".

1) even if you wish to delay the loading and resource consumption until

actually needed, adding a "hard" dependency�mode where dependencies

are registered early at one point in time (but marked unneeded or something)

likely helps QA and more. Its tricky QA with "soft" lazily loaded depndency chains,

some KISS functionality (I'd do --enable-hard-deps or similar) helps build

mommas doing distro QA.

Exactly. Even soft dependencies must be registered/known before booting or be dynamically registered using a deterministic resolver. That is what the program.json file is for. Only stuff declared in program.json is allowed to go into the runtime of the program. Once a dependency is registered (multiple versions of same dependency is allowed) it can be mapped into the namespace of a package using package.json.

I am talking here about the package level, not the module level. Module resolving happens *within* a package only where external dependecies are mapped into the package's own namespace. This makes resolving modules completely deterministic as well.

Upon first invocation, if B cannot be resolved, the require call must throw an exception.� It is not defined whether it is allowed to succeed on a subsequent call.

Everyone gotta be doing the exceptions, sigh. But with an early/hard dependency registration

you might be able to displatya reasonable error message etc in the exception handler

(and perhaps warn early if no resolution seems viable even though you MUST

evaluate later at specific instance in time for "soft" deps. There's also the possibility

of greedy/asynchronous downloading (not that JS modules/packages will ever be 100's

Mb's but its a nice touch anyways).

PINF boots a program by first registering all dependencies allowed for the program from the program.json file. A lot of validation already happens there. These dependencies are then mapped into packages and by scraping require()s in the modules we can ensure all dependencies are resolved prior to loading the module. There is complete information about what did not resolve available although I don't have really pretty errors yet.

PINF can do greedy or lazy async downloading as dependencies are required.

In Modules/2.0-draft8, which is not an official standard, module dependencies are declared along with the module. Web-browser based module loaders will resolve the dependencies (but not initialize the module) before the application starts, to avoid blocking calls.� The behaviour in /1.1.1 is also permitted.� It is allowable, but not required, for a Modules/2.0-draft8 system to resolve a module which was not explicitly named in the module dependencies.�
�

Good: Modules 2.0 starts to sound what I've just described.

The other thing to start think about is a way to automate the dependency chains

without the need for specific overloading of requires("foo") as also

a dependency marker.

I point you at

/bin/bash --rpm-requires foo.sh

which basically drills into the shell parser (because writing a separate shell parser

is a hugely complex task) and finds every occurence of

tokens in an executable context and emits those, but doesn't execute anything whatsoever.

What I'm suggesting is something similar for gar(1): a means to parse *.js

and pull out every token that indicates an external need: even if all your

are doing si applying a pattern to pull "foo" out of

�requires("foo") �

its useful (imho) to be able to extract all script pre-requisites efficiently.

Yup. We call that "require scraping". I can boot a complex application with PINF pulling in package and module dependencies in various formats and then export a pristine program with all dependencies collapsed into small namespace and only containing modules that are already used. By following module.load() calls (which is the only entry point for pulling in NEW dependencies into a runtime) I can also generate inlined JS code where the initial program consists of one JS file and every set of dynamically loaded dependencies is another inline JS file.

This all works today and is heavily used to generate optimized programs for browser loading.

You can try and run: https://github.com/cadorn/ace-extjs (not sure if it currently works ... lots of changes to the loader have been pushed since I last tested). I can make sure it works if you are interested in looking at it.

With GPSEE these inlined JS files can even be compiled so no source is ever shipped.

BTW, dependency hell is more likely - I think - to happen between packages than between modules.� Packages are collections of modules.� In this context, modules tend to be more like C programs and object files, whereas packages tend to be more like solibs.� GPSEE does not support packages natively, but Christoph's PINF loader adds that capability.
�

Oooh, nice, noted.

I'll have to stare at what CommonJS wishes as package markup and think: yes I've

looked, its a bit naive and flimsy for my taste atm (but packaging is a prfessional hazard

her, RPM is known to cause insanity, me included).

I have been wrestling with packages and dependencies for a couple of years now. It can certainly make your head hurt but I think I got a good solution now. What is implemented in PINF I would like to see in CommonJS. The CommonJS specs are close but there is some stuff missing. FYI, The same concepts used in PINF to work with CommonJS packages will be made available to PHP packages as well and then other languages. I think the separation of concerns the way I have implemented things is sound and completely transferable to many package systems and runtimes. Some languages will have more success than others depending on their ability to namespace things internally in the runtime. Where that is not available a JIT precompiler via GPSEE could be embedded.

Christoph