module tests for Classic ASP?

[Pete Duncanson]

Is there an set of tests that I can run for modules?

I've found the one in Narwhal's /tests/commonjs/modules which needs to use the /lib/test/ goodies. Trouble is that all relies on file etc. which are included using "require" and I don't have versions of file etc. running on ASP yet :(

I'm using Nathan Smiths "require" functionality but I want to make sure its behaving as it should. Any tips on how to quickly hack the test framework to run outside of Narwhal?

I'll have a play around but any pointers welcome :)

[Kris Kowal]

On Wed, Jan 13, 2010 at 1:11 PM, Pete Duncanson
<pete.du...@googlemail.com> wrote:
> Is there an set of tests that I can run for modules?

To run each of the modules tests, you need a scaffold that:

* arranges for the test's root directory to be where, or one of the
places where, top level modules are sought.
* a print(message) free variable, or require("system").stdout.print(message).

http://github.com/kriskowal/commonjs/tree/master/tests/modules/1.0/

Kris Kowal

[Thomas Aylott]

Tf you do get something working, please be so kind as to share it.
I'm going to be experimenting with JScript ASP in the coming weeks or so.
It'd be awesome to be able to support CommonJS and run the tests
proving that it works.

Thanks.

— Thomas Aylott
SubtleGradient
MooTools

[Pete Duncanson]

Had a play with this over the weekend and seem to be getting some where.

First test I tried though is absolute, and its falling over trying to import /tests/modules/1.0/absolute/b.js from /tests/modules/1.0/absolute/submodule/a.js

Now b.js exists but a.js is including it via the term "b" which to me would mean its expecting it to be in the same folder but its not. That got me thinking that I've not got my head around this correctly.

I need to ask some questions though just to clear up some queries to make sure I have a understanding of how all this is to work (sorry but I struggle with NASA style clarity of language alot, prefer samples).

- Module identifiers may be "relative" or "top-level". A module identifier is "relative" if the first term is "." or ".."

So if "." or ".." then it HAS to be top-level. As in it has to be relative from the root:

So in file /work/test.js:

require("a") --> /a ?
require("./b" --> /work/b
require("/c") --> /c
require("../d") --> /d

I'd have thought require("a") would look in the same folder as the calling file? Confused :(

- Top-level identifiers are resolved off the conceptual module name space root.

Does this answer my query above? What the hell is the conceptual module name space root? :)

- Relative identifiers are resolved relative to the identifier of the module in which "require" is written and called

I think this is the reason my codes not running. Heres how I "think" it should be working, please correct me if wrong:

/modules/1.0/absolute/program requires:
- "test" --> Who's working directory should be the same as program (/modules/1.0/absolute)
- "submodule/a" --> same wd as test (think this is where I'm going wrong though, think I'm assuming its wd is /modules/1.0/absolute/submodule)
- "b" --> same wd as test

/modules/1.0/absolute/test requires nothing

/modules/1.0/absolute/submodule/a requires
- "b" --> but its looking relative in /modules/1.0/absolute/submodule so does not find it as it "should" be looking in /modules/1.0/absolute as thats where "a" was originally included from? EG the working directory should not have changed

//modules/1.0/absolute/b requires nothing

Hmmm even writting it out here has made it a little clear but would still like something to double check if someone could? 

 - If there is a dependency cycle, the foreign module may not have finished executing at the time it is required by one of its transitive dependencies; in this case, the object returned by "require" must contain at least the exports that the foreign module has prepared before the call to require that led to the current module's execution.

Do you mean module a includes b which includes c which in turn includes a? So a never returns. How the heck do you stop that happening?

Cheers

Pete

--
You received this message because you are subscribed to the Google Groups "CommonJS" group.
To post to this group, send email to comm...@googlegroups.com.
To unsubscribe from this group, send email to commonjs+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/commonjs?hl=en.

[Wes Garland]

Pete:

The important realization is that your CommonJS "program" is also a module. There is also the concept of a module path, which is searched for "top-level" modules.

So, say your module path is C:\MP and your program is in C:\JS\myprogram.js

From your program, then,

require("a") -> C:\MP\a.js
require("./a") -> C:\JS\a.js
require("../a") -> C:\a.js
require("./lib/b") -> C:\JS\lib\b.js

Now, if your module C:\JS\lib\b.js calls require,

require("a") -> C:\MP\a.js
require("./a") -> C:\JS\lib\a.js
require("../a") -> C:\JS\a.js
require("./lib/b") -> C:\JS\lib\lib\b.js

Also, if the spec says "." and "..", it needs to be ammended.  It should read "./" and "../".  The difference is subtle, yet important.

- Top-level identifiers are resolved off the conceptual module name space root.

Does this answer my query above? What the hell is the conceptual module name space root? :)

I call it the module path
 

Do you mean module a includes b which includes c which in turn includes a? So a never returns. How the heck do you stop that happening?

This is solved by following the spec, except possibly in convoluted esoteric cases.  Just make sure your modules populate an extant exports objects and you're good to go. This is why we don't return modules' exports.

Wes

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

[Pete Duncanson]

Wes, straight away thats made things alot clearer.

Looking forward to some more hacking tonight now :)

If anyone else wants to shine some more light please do, the brighter the better. I'm not a stupid guy but I do struggle with the language of some of the specs, something I'm working on though.

Cheers

Pete