Re: [gpsee] GPSEE has a "hybrid" ABI
6 views
Skip to first unread message
Wes Garland
Sep 23, 2011, 4:27:22 PM9/23/11
to gp...@googlegroups.com
>
the "hybrid" ABI forces the application to link both -lgpsee and -lmozjs85.
What do you think off the current solution, which is to link -lmozjs185 from -lgpsee?
The one place I'm aware of where this gets its ugly is that embeddings which load like the library that links -lgpsee by dlopen can have a hard time getting at the symbols in libmozjs. This has already caused pain in APE; I solved it with dlopen("libape_spidermonkey.so", RTLD_LAZY | RTLD_GLOBAL);. libape_spidermonkey.so is -lgpsee.
The current naming convention (ugh btw) is that functions named JS_XYZ are either in JSAPI or behave exactly the ones in some version of JSAPI, where as gpsee_XYZ is *like* JS_XYZ but different in some way that matters. The example you quoted is an important one; memory allocation is different. (JS_ using magic, gpsee_ using alloca()).
I've considered this; I just haven't figured out exactly how much JSAPI I want to LTS. :)
Out of curiosity, why are doing this?
You're right, this is a problem. Right now it's 80% in my brain and 20% in the blog. That's not nearly good enough.
Make sure you read spidermonkey/probe-jsapi.*, most of my 1.8.2 -> 1.8.5 knowledge is recorded there.
Wes
--
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102
What do you think off the current solution, which is to link -lmozjs185 from -lgpsee?
The one place I'm aware of where this gets its ugly is that embeddings which load like the library that links -lgpsee by dlopen can have a hard time getting at the symbols in libmozjs. This has already caused pain in APE; I solved it with dlopen("libape_spidermonkey.so", RTLD_LAZY | RTLD_GLOBAL);. libape_spidermonkey.so is -lgpsee.
Some JS_FooBarBaz() functions in -lmozjs185 are presented/used directly,
others are wrapped by GPSEE (like gpsee_getStringBytes).
The current naming convention (ugh btw) is that functions named JS_XYZ are either in JSAPI or behave exactly the ones in some version of JSAPI, where as gpsee_XYZ is *like* JS_XYZ but different in some way that matters. The example you quoted is an important one; memory allocation is different. (JS_ using magic, gpsee_ using alloca()).
All I'm tryying to say/suggest is that you might want to wrap a few
more routineswith gpsee_fooBarBaz().
I've considered this; I just haven't figured out exactly how much JSAPI I want to LTS. :)
JS_DestroyRuntime(JS_NewRuntime(1024));
Out of curiosity, why are doing this?
I'm not sure ABI matters a bit, but "hybrid" leads to some confusing issues like
Who documents JS_GetSTringBytes() replacements and breakage?
You're right, this is a problem. Right now it's 80% in my brain and 20% in the blog. That's not nearly good enough.
on to RPMJS modules, sure to be all sorts of compilation breakage there
Make sure you read spidermonkey/probe-jsapi.*, most of my 1.8.2 -> 1.8.5 knowledge is recorded there.
Wes
--
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102
Jeff Johnson
Sep 23, 2011, 4:51:38 PM9/23/11
to gp...@googlegroups.com
On Sep 23, 2011, at 4:27 PM, Wes Garland wrote:
> the "hybrid" ABI forces the application to link both -lgpsee and -lmozjs85.
What do you think off the current solution, which is to link -lmozjs185 from -lgpsee?
There's a modest (and mostly minuscule) peformance increase
in ELF loaders with fewer symbols.
But there's so so so many DSO's in use these days that it likely
maytters not at all.
(aside)
My concerns are rather obscure: If I say RPM+JS, thgen I will have
instant feature requests and bug reports because I choose not to
link every possible -ljs that exists. So GPSEE is a prophylactic
to fend off the bug reports (and add module loading, and
commonjs, and signal handling, and your sane/savvy expertise: its
not just avoiding backwards looking feature requests with RPM+GPSEE).
The one place I'm aware of where this gets its ugly is that embeddings which load like the library that links -lgpsee by dlopen can have a hard time getting at the symbols in libmozjs. This has already caused pain in APE; I solved it with dlopen("libape_spidermonkey.so", RTLD_LAZY | RTLD_GLOBAL);. libape_spidermonkey.so is -lgpsee.
There's no win with embedded and dlopen: its all the wild west there.
Some JS_FooBarBaz() functions in -lmozjs185 are presented/used directly,
others are wrapped by GPSEE (like gpsee_getStringBytes).
The current naming convention (ugh btw) is that functions named JS_XYZ are either in JSAPI or behave exactly the ones in some version of JSAPI, where as gpsee_XYZ is *like* JS_XYZ but different in some way that matters. The example you quoted is an important one; memory allocation is different. (JS_ using magic, gpsee_ using alloca()).
Got it: sane rules, nice.
All I'm tryying to say/suggest is that you might want to wrap a few
more routineswith gpsee_fooBarBaz().
I've considered this; I just haven't figured out exactly how much JSAPI I want to LTS. :)
JS_DestroyRuntime(JS_NewRuntime(1024));
Out of curiosity, why are doing this?
No frigging clue: I swiiped this code straight from either jsshell (or as I got
smarter) GPSEE.
The fuller context is this
if (F_ISSET(flags, NOUTF8) || getenv("GPSEE_NO_UTF8_C_STRINGS")) {
JS_DestroyRuntime(JS_NewRuntime(1024));
putenv((char *) "GPSEE_NO_UTF8_C_STRINGS=1");
}
while creating a "rpmjs" object wrapper carrying around a GPSEE interpreter opaquely.
I'm not sure ABI matters a bit, but "hybrid" leads to some confusing issues like
Who documents JS_GetSTringBytes() replacements and breakage?
You're right, this is a problem. Right now it's 80% in my brain and 20% in the blog. That's not nearly good enough.
I can likely give you a laundry list of problems since JS 1.8.1 shortly. I
can fish the laundry list out of CVS anytime too ...
on to RPMJS modules, sure to be all sorts of compilation breakage there
Make sure you read spidermonkey/probe-jsapi.*, most of my 1.8.2 -> 1.8.5 knowledge is recorded there.
Known: not yet sure what to do, but I'm absolutely positive
that the feature set of JS can be discovered.
You might want to make this run-time discoverable.
NEON is another piece of middleware (like GPSEE used for embedding and APRS used everywhere)
that has a run-time interface to enquire what the feature set is.
PCRE is another project with a complex set of features compiled in that uses
a run-time interface to access.
run-time (and programming logic) is often more "production" (and LTS) ready than trying
to deal with compile time features that flip in and out. An ABI with a constant set of
methods, some of which return UNIMPLEMENTED errors, is easier maintenance
than symbo9ls that appear/disappear magically. You are already well down this path
with the exceptions that you are throwing in GPSEE if features aren't compiled in.
73 de Jeff
Jeff Johnson
Sep 23, 2011, 4:10:33 PM9/23/11
to gp...@googlegroups.com
w00t! (from me)
[jbj@wp3 wdj54]$ ./rpm -E '%{js:print("w00t!")}'
w00t!
Segmentation fault
All it took was s/JS_GetStringBytes/gpsee_getStringBytes/ in 1 place.
(aside while I'm here)
GPSEE has a tricky ABI design problem because its a piece of middleware.
Some JS_FooBarBaz() functions in -lmozjs185 are presented/used directly,
others are wrapped by GPSEE (like gpsee_getStringBytes).
This leads to a "hybrid" ABI for perfectly obvious reasons.
But from a stricter more pedantic POV (I don't care what RPM does:
once you reach linking 80+ libraries one more or less simply doesn't matter),
the "hybrid" ABI forces the application to link both -lgpsee and -lmozjs85.
The alternative and pedantically correct ABI rewraps all JS_FooBarBaz()
into gpsee_fooBarBaz() and there's an implicit inter-library linkage, not an application
linkage of all possible libraries.
All of which "works" fine but is perhaps not "correct".
All I'm tryying to say/suggest is that you might want to wrap a few
more routineswith gpsee_fooBarBaz().
Here's the handfule of JS_FooBarBaz routines in use by RPM+GPSEE that might be
candidates for re-wrapping (and might already be re-wrapped, not looked carefully)
JS_DestroyRuntime(JS_NewRuntime(1024));
gpsee_runtime_t * grt = JS_GetRuntimePrivate(JS_GetRuntime(I->cx));
JS_SetOptions(I->cx, (flags & 0xffff));
JS_SetGCZeal(I->cx, _rpmjs_zeal);
ok = JS_EvaluateScript(I->cx, I->realm->globalObject, str, strlen(str), __FILE__, __LINE__, &v);
JSString *rstr = JS_ValueToString(I->cx, v);
These are just the methods (and affect ABI): there's another whole level of pointless pedantry
rewrapping constants like JS_TRUE and JS_FALSE and typedefs etc that don't show up directly
(well size of data/bss symbols matters) in the ABI.
I'm not sure ABI matters a bit, but "hybrid" leads to some confusing issues like
Who documents JS_GetSTringBytes() replacements and breakage?
73 de Jeff on to RPMJS modules, sure to be all sorts of compilation breakage there
Christoph Dorn
Sep 23, 2011, 5:49:59 PM9/23/11
to gp...@googlegroups.com
Jeff Johnson wrote:
> [jbj@wp3 wdj54]$ ./rpm -E '%{js:print("w00t!")}'
> w00t!
> [jbj@wp3 wdj54]$ ./rpm -E '%{js:print("w00t!")}'
> w00t!
Is this for allowing JS scripting when configuring/compiling source code
via RPM?
What is the lifecycle of the JS context?
Will it be possible to init a JS context once in the beginning (which
can load various CommonJS packages/modules) and then calling into that
repeatedly later? That would be ideal to minimize init overhead when
using more complex JS scripting composed of many modules.
Ignore this if I am interpreting this all wrong :)
Christoph
Jeff Johnson
Sep 23, 2011, 6:16:41 PM9/23/11
to gp...@googlegroups.com
On Sep 23, 2011, at 5:49 PM, Christoph Dorn wrote:
> Jeff Johnson wrote:
>> [jbj@wp3 wdj54]$ ./rpm -E '%{js:print("w00t!")}'
>> w00t!
>
> Is this for allowing JS scripting when configuring/compiling source code via RPM?
>
The ultimate motivation is not user focussed at all, but rather converting
RPM from C to JS as a development language. That means my central
focus is all about binding existing RPM objects in C with methods
for use in JS.
Meanwhile, RPM has undertaken interpreter embeddings for just about every
language in which one might consider doing development. RPM has a unique
application niche because a software installer is expected to Just Work
on bare metal hardware and in empty chroot's. There's only a few solutions
for that constraint, one of which is embedding.
So the two user visible uses of RPM+JS are analogues of an uglix script like
#!INTERPRETER OPTIONS ARGS
BODY
or (with a "here" document
INTERPRETER OPTIONS ARGS << EOF
BODY
EOF
One usage case is with macro expansions used in templating with a programming signature like
%{INTERPRETER OPTIONS ARGS:BODY}
and the macro expansion captures stout into a memory buffer for template substitution
(and further processing).
The other usage case is a replacement for %post et al scripting performed while
installing package software with syntax in a spec file like
%post -p '<INTERPRETER OPTS ARGS>'
BODY
where one can avoid dependency on prerequisites necessary to perform a scripted operation.
Note that the BODY is also macro expanded so templating/scripting can be used together
(though the expansion operation will be during expansion, not while executing the BODY
> What is the lifecycle of the JS context?
>
Varies. There's a flag to use/share a single refcounted global interpreter, or
to be able to create/destroy multiple interpreters in their own context. Some languages
(python and ruby iirc) do not permit multiple interpreter instances, other
languages d, so there's a need outside of JS to share <-> isolate contexts
just to accommodate single instance interpreters.
A global shared interpreter is the easier paradigm to understand no matter what
else is feasible.
> Will it be possible to init a JS context once in the beginning (which can load various CommonJS packages/modules) and then calling into that repeatedly later? That would be ideal to minimize init overhead when using more complex JS scripting composed of many modules.
>
Yes: each instance has a preamble that can be expanded to load modules (I hesitate to say package,
because I have rather different associations there: I see a CommonJS "package" as a bundle of "modules"
abstraction, rather different than a *.rpm package because files != modules, files are purely content).
> Ignore this if I am interpreting this all wrong :)
>
No worries: I'm just sniffing gasoline and making up the usage case as I proceed.
I'll easily recognize the tools that I want to develop with in JS as soon as I create them.
73 de Jeff
Christoph Dorn
Sep 23, 2011, 7:39:46 PM9/23/11
to gp...@googlegroups.com
Jeff Johnson wrote:
> Will it be possible to init a JS context once in the beginning (which can load various CommonJS packages/modules) and then calling into that repeatedly later? That would be ideal to minimize init overhead when using more complex JS scripting composed of many modules. >Yes: each instance has a preamble that can be expanded to load modules (I hesitate to say package, because I have rather different associations there: I see a CommonJS "package" as a bundle of "modules" abstraction, rather different than a *.rpm package because files != modules, files are purely content).
CommonJS "package" as a bundle of "modules" abstraction is
largely correct. A CommonJS package is a logical unit of modules and may
be arbitrarily structured (including all modules inlined into one
file). Where does the fact that CommonJS packages have their own
sovereign modules namespace and declare their external dependencies fit
into your POV?
Should I be using cjs-package in future so we can distinguish better when referring to "package"?
The stuff you are doing with RPM sounds great. Exactly the kind of thing I have been hoping we would get to eventually. My interest in it would be to visualize all the different contexts (no matter what language) and what is going on when running an RPM command by hooking into strategic places under the hood and making internal data available via a backchannel. The data would then be aggregated/organized and streamed to a client to visualize in realtime (2D and 3D) so you can see relationships much better than what is possible by observing one dimensional logs. If different contexts are defined by URIs and file and line info is available we can jump from the visual right to the file to make changes.
For example, the following data generates the following visual in a client. To log groups etc.. no context must be kept by the logger (read many logging sources). One can log arbitrary messages to arbitrary data channels in arbitrary sequence which can get arbitrarily aggregated at various stages. All implemented in MIT CommonJS, needs some love, review, refactoring, optimization and additions but the core plumbing and tooling is there to make something work.
(The visual is an example of some simple console renderers. Renderers are CommonJS modules so any visualization is possible depending on the data and data relationships provided by the backend.)
x-wf-protocol-1: http://registry.pinf.org/cadorn.org/wildfire/@meta/protocol/component/0.1.0
x-wf-1-index: 31
x-wf-1-1-receiver: http://registry.pinf.org/cadorn.org/insight/@meta/receiver/insight/controller/0
x-wf-1-1-1-sender: http://registry.pinf.org/cadorn.org/github/firephp-libs/programs/standalone/examples/TestRunner/?lib=cadorn.org/github/firephp-libs/packages/ins...@0.0.0master1106021548
x-wf-1-1-1-1: 56||{"action":"inspectRequest","actionArgs":{"options":[]}}|
x-wf-1-2-receiver: http://registry.pinf.org/cadorn.org/insight/@meta/receiver/console/request/0
x-wf-1-2-1-sender: http://registry.pinf.org/cadorn.org/github/firephp-libs/programs/standalone/examples/TestRunner/?lib=cadorn.org/github/firephp-libs/packages/ins...@0.0.0master1106021548
x-wf-1-2-1-2: 364|{"context":"request","target":"console\/Messages","file":"\/pinf\/programs\/com.developercompanion.reference\/packages\/lib-php-standalone\/examples\/TestRunner\/insight-devcomp\/RequestConsole-Groups.php","line":7,"lang.id":"registry.pinf.org\/cadorn.org\/github\/renderers\/packages\/php\/master"}|{"origin":{"type":"text","text":"Message","lang.type":"string"}}|
x-wf-1-1-1-3: 82||{"action":"inspectRequest","actionArgs":{"options":{"target":"console\/Groups"}}}|
x-wf-1-2-1-4: 405|{"context":"request","target":"console\/Groups","group":"Group1","group.start":true,"file":"\/pinf\/programs\/com.developercompanion.reference\/packages\/lib-php-standalone\/examples\/TestRunner\/insight-devcomp\/RequestConsole-Groups.php","line":12,"lang.id":"registry.pinf.org\/cadorn.org\/github\/renderers\/packages\/php\/master"}|{"origin":{"type":"constant","constant":"true","lang.type":"boolean"}}|
x-wf-1-2-1-5: 367|{"context":"request","target":"console\/Groups","file":"\/pinf\/programs\/com.developercompanion.reference\/packages\/lib-php-standalone\/examples\/TestRunner\/insight-devcomp\/RequestConsole-Groups.php","line":14,"lang.id":"registry.pinf.org\/cadorn.org\/github\/renderers\/packages\/php\/master"}|{"origin":{"type":"text","text":"Group Title","lang.type":"string"}}|
x-wf-1-2-1-6: 365|{"context":"request","target":"console\/Groups","file":"\/pinf\/programs\/com.developercompanion.reference\/packages\/lib-php-standalone\/examples\/TestRunner\/insight-devcomp\/RequestConsole-Groups.php","line":15,"lang.id":"registry.pinf.org\/cadorn.org\/github\/renderers\/packages\/php\/master"}|{"origin":{"type":"text","text":"Message 1","lang.type":"string"}}|
x-wf-1-2-1-7: 365|{"context":"request","target":"console\/Groups","file":"\/pinf\/programs\/com.developercompanion.reference\/packages\/lib-php-standalone\/examples\/TestRunner\/insight-devcomp\/RequestConsole-Groups.php","line":16,"lang.id":"registry.pinf.org\/cadorn.org\/github\/renderers\/packages\/php\/master"}|{"origin":{"type":"text","text":"Message 2","lang.type":"string"}}|
x-wf-1-2-1-8: 367|{"context":"request","target":"console\/Messages","file":"\/pinf\/programs\/com.developercompanion.reference\/packages\/lib-php-standalone\/examples\/TestRunner\/insight-devcomp\/RequestConsole-Groups.php","line":18,"lang.id":"registry.pinf.org\/cadorn.org\/github\/renderers\/packages\/php\/master"}|{"origin":{"type":"text","text":"Message 3","lang.type":"string"}}|
x-wf-1-2-1-9: 403|{"context":"request","target":"console\/Groups","group":"Group1","group.end":true,"file":"\/pinf\/programs\/com.developercompanion.reference\/packages\/lib-php-standalone\/examples\/TestRunner\/insight-devcomp\/RequestConsole-Groups.php","line":20,"lang.id":"registry.pinf.org\/cadorn.org\/github\/renderers\/packages\/php\/master"}|{"origin":{"type":"constant","constant":"true","lang.type":"boolean"}}|
x-wf-1-2-1-10: 244|{"context":"request","target":"console\/Groups","group":"Group2","group.expand":"Group2","lang.id":"registry.pinf.org\/cadorn.org\/github\/renderers\/packages\/php\/master"}|{"origin":{"type":"text","text":"Group 2 Title","lang.type":"string"}}|
x-wf-1-2-1-11: 429|{"context":"request","target":"console\/Groups","group":"Group2","group.expand":"Group2","group.start":true,"file":"\/pinf\/programs\/com.developercompanion.reference\/packages\/lib-php-standalone\/examples\/TestRunner\/insight-devcomp\/RequestConsole-Groups.php","line":24,"lang.id":"registry.pinf.org\/cadorn.org\/github\/renderers\/packages\/php\/master"}|{"origin":{"type":"constant","constant":"true","lang.type":"boolean"}}|
x-wf-1-2-1-12: 365|{"context":"request","target":"console\/Groups","file":"\/pinf\/programs\/com.developercompanion.reference\/packages\/lib-php-standalone\/examples\/TestRunner\/insight-devcomp\/RequestConsole-Groups.php","line":26,"lang.id":"registry.pinf.org\/cadorn.org\/github\/renderers\/packages\/php\/master"}|{"origin":{"type":"text","text":"Message 1","lang.type":"string"}}|
x-wf-1-2-1-13: 365|{"context":"request","target":"console\/Groups","file":"\/pinf\/programs\/com.developercompanion.reference\/packages\/lib-php-standalone\/examples\/TestRunner\/insight-devcomp\/RequestConsole-Groups.php","line":27,"lang.id":"registry.pinf.org\/cadorn.org\/github\/renderers\/packages\/php\/master"}|{"origin":{"type":"text","text":"Message 2","lang.type":"string"}}|
x-wf-1-2-1-14: 427|{"context":"request","target":"console\/Groups","group":"Group2","group.expand":"Group2","group.end":true,"file":"\/pinf\/programs\/com.developercompanion.reference\/packages\/lib-php-standalone\/examples\/TestRunner\/insight-devcomp\/RequestConsole-Groups.php","line":29,"lang.id":"registry.pinf.org\/cadorn.org\/github\/renderers\/packages\/php\/master"}|{"origin":{"type":"constant","constant":"true","lang.type":"boolean"}}|
x-wf-1-2-1-15: 244|{"context":"request","target":"console\/Groups","group":"Group3","group.expand":"Group3","lang.id":"registry.pinf.org\/cadorn.org\/github\/renderers\/packages\/php\/master"}|{"origin":{"type":"text","text":"Group 3 Title","lang.type":"string"}}|
x-wf-1-2-1-16: 429|{"context":"request","target":"console\/Groups","group":"Group3","group.expand":"Group3","group.start":true,"file":"\/pinf\/programs\/com.developercompanion.reference\/packages\/lib-php-standalone\/examples\/TestRunner\/insight-devcomp\/RequestConsole-Groups.php","line":33,"lang.id":"registry.pinf.org\/cadorn.org\/github\/renderers\/packages\/php\/master"}|{"origin":{"type":"constant","constant":"true","lang.type":"boolean"}}|
x-wf-1-2-1-17: 365|{"context":"request","target":"console\/Groups","file":"\/pinf\/programs\/com.developercompanion.reference\/packages\/lib-php-standalone\/examples\/TestRunner\/insight-devcomp\/RequestConsole-Groups.php","line":35,"lang.id":"registry.pinf.org\/cadorn.org\/github\/renderers\/packages\/php\/master"}|{"origin":{"type":"text","text":"Message 1","lang.type":"string"}}|
x-wf-1-2-1-18: 427|{"context":"request","target":"console\/Groups","group":"Group3","group.expand":"Group3","group.end":true,"file":"\/pinf\/programs\/com.developercompanion.reference\/packages\/lib-php-standalone\/examples\/TestRunner\/insight-devcomp\/RequestConsole-Groups.php","line":37,"lang.id":"registry.pinf.org\/cadorn.org\/github\/renderers\/packages\/php\/master"}|{"origin":{"type":"constant","constant":"true","lang.type":"boolean"}}|
x-wf-1-2-1-19: 244|{"context":"request","target":"console\/Groups","group":"Group4","group.expand":"Group4","lang.id":"registry.pinf.org\/cadorn.org\/github\/renderers\/packages\/php\/master"}|{"origin":{"type":"text","text":"Group 4 Title","lang.type":"string"}}|
x-wf-1-2-1-20: 429|{"context":"request","target":"console\/Groups","group":"Group4","group.expand":"Group4","group.start":true,"file":"\/pinf\/programs\/com.developercompanion.reference\/packages\/lib-php-standalone\/examples\/TestRunner\/insight-devcomp\/RequestConsole-Groups.php","line":40,"lang.id":"registry.pinf.org\/cadorn.org\/github\/renderers\/packages\/php\/master"}|{"origin":{"type":"constant","constant":"true","lang.type":"boolean"}}|
x-wf-1-2-1-21: 365|{"context":"request","target":"console\/Groups","file":"\/pinf\/programs\/com.developercompanion.reference\/packages\/lib-php-standalone\/examples\/TestRunner\/insight-devcomp\/RequestConsole-Groups.php","line":42,"lang.id":"registry.pinf.org\/cadorn.org\/github\/renderers\/packages\/php\/master"}|{"origin":{"type":"text","text":"Message 1","lang.type":"string"}}|
x-wf-1-2-1-22: 406|{"context":"request","target":"console\/Groups","group":"Group41","group.start":true,"file":"\/pinf\/programs\/com.developercompanion.reference\/packages\/lib-php-standalone\/examples\/TestRunner\/insight-devcomp\/RequestConsole-Groups.php","line":44,"lang.id":"registry.pinf.org\/cadorn.org\/github\/renderers\/packages\/php\/master"}|{"origin":{"type":"constant","constant":"true","lang.type":"boolean"}}|
x-wf-1-2-1-23: 367|{"context":"request","target":"console\/Groups","file":"\/pinf\/programs\/com.developercompanion.reference\/packages\/lib-php-standalone\/examples\/TestRunner\/insight-devcomp\/RequestConsole-Groups.php","line":46,"lang.id":"registry.pinf.org\/cadorn.org\/github\/renderers\/packages\/php\/master"}|{"origin":{"type":"text","text":"Group Title","lang.type":"string"}}|
x-wf-1-2-1-24: 365|{"context":"request","target":"console\/Groups","file":"\/pinf\/programs\/com.developercompanion.reference\/packages\/lib-php-standalone\/examples\/TestRunner\/insight-devcomp\/RequestConsole-Groups.php","line":47,"lang.id":"registry.pinf.org\/cadorn.org\/github\/renderers\/packages\/php\/master"}|{"origin":{"type":"text","text":"Message 1","lang.type":"string"}}|
x-wf-1-2-1-25: 365|{"context":"request","target":"console\/Groups","file":"\/pinf\/programs\/com.developercompanion.reference\/packages\/lib-php-standalone\/examples\/TestRunner\/insight-devcomp\/RequestConsole-Groups.php","line":48,"lang.id":"registry.pinf.org\/cadorn.org\/github\/renderers\/packages\/php\/master"}|{"origin":{"type":"text","text":"Message 2","lang.type":"string"}}|
x-wf-1-2-1-26: 367|{"context":"request","target":"console\/Messages","file":"\/pinf\/programs\/com.developercompanion.reference\/packages\/lib-php-standalone\/examples\/TestRunner\/insight-devcomp\/RequestConsole-Groups.php","line":50,"lang.id":"registry.pinf.org\/cadorn.org\/github\/renderers\/packages\/php\/master"}|{"origin":{"type":"text","text":"Message 3","lang.type":"string"}}|
x-wf-1-2-1-27: 404|{"context":"request","target":"console\/Groups","group":"Group41","group.end":true,"file":"\/pinf\/programs\/com.developercompanion.reference\/packages\/lib-php-standalone\/examples\/TestRunner\/insight-devcomp\/RequestConsole-Groups.php","line":52,"lang.id":"registry.pinf.org\/cadorn.org\/github\/renderers\/packages\/php\/master"}|{"origin":{"type":"constant","constant":"true","lang.type":"boolean"}}|
x-wf-1-2-1-28: 404|{"context":"request","target":"console\/Groups","group":"Group41","group.end":true,"file":"\/pinf\/programs\/com.developercompanion.reference\/packages\/lib-php-standalone\/examples\/TestRunner\/insight-devcomp\/RequestConsole-Groups.php","line":54,"lang.id":"registry.pinf.org\/cadorn.org\/github\/renderers\/packages\/php\/master"}|{"origin":{"type":"constant","constant":"true","lang.type":"boolean"}}|
x-wf-1-2-1-29: 244|{"context":"request","target":"console\/Groups","group":"Group5","group.expand":"Group5","lang.id":"registry.pinf.org\/cadorn.org\/github\/renderers\/packages\/php\/master"}|{"origin":{"type":"text","text":"Group 5 Title","lang.type":"string"}}|
x-wf-1-2-1-30: 429|{"context":"request","target":"console\/Groups","group":"Group5","group.expand":"Group5","group.start":true,"file":"\/pinf\/programs\/com.developercompanion.reference\/packages\/lib-php-standalone\/examples\/TestRunner\/insight-devcomp\/RequestConsole-Groups.php","line":56,"lang.id":"registry.pinf.org\/cadorn.org\/github\/renderers\/packages\/php\/master"}|{"origin":{"type":"constant","constant":"true","lang.type":"boolean"}}|
x-wf-1-2-1-31: 427|{"context":"request","target":"console\/Groups","group":"Group5","group.expand":"Group5","group.end":true,"file":"\/pinf\/programs\/com.developercompanion.reference\/packages\/lib-php-standalone\/examples\/TestRunner\/insight-devcomp\/RequestConsole-Groups.php","line":58,"lang.id":"registry.pinf.org\/cadorn.org\/github\/renderers\/packages\/php\/master"}|{"origin":{"type":"constant","constant":"true","lang.type":"boolean"}}|
Christoph
Should I be using cjs-package in future so we can distinguish better when referring to "package"?
The stuff you are doing with RPM sounds great. Exactly the kind of thing I have been hoping we would get to eventually. My interest in it would be to visualize all the different contexts (no matter what language) and what is going on when running an RPM command by hooking into strategic places under the hood and making internal data available via a backchannel. The data would then be aggregated/organized and streamed to a client to visualize in realtime (2D and 3D) so you can see relationships much better than what is possible by observing one dimensional logs. If different contexts are defined by URIs and file and line info is available we can jump from the visual right to the file to make changes.
For example, the following data generates the following visual in a client. To log groups etc.. no context must be kept by the logger (read many logging sources). One can log arbitrary messages to arbitrary data channels in arbitrary sequence which can get arbitrarily aggregated at various stages. All implemented in MIT CommonJS, needs some love, review, refactoring, optimization and additions but the core plumbing and tooling is there to make something work.
(The visual is an example of some simple console renderers. Renderers are CommonJS modules so any visualization is possible depending on the data and data relationships provided by the backend.)
x-wf-protocol-1: http://registry.pinf.org/cadorn.org/wildfire/@meta/protocol/component/0.1.0
x-wf-1-index: 31
x-wf-1-1-receiver: http://registry.pinf.org/cadorn.org/insight/@meta/receiver/insight/controller/0
x-wf-1-1-1-sender: http://registry.pinf.org/cadorn.org/github/firephp-libs/programs/standalone/examples/TestRunner/?lib=cadorn.org/github/firephp-libs/packages/ins...@0.0.0master1106021548
x-wf-1-1-1-1: 56||{"action":"inspectRequest","actionArgs":{"options":[]}}|
x-wf-1-2-receiver: http://registry.pinf.org/cadorn.org/insight/@meta/receiver/console/request/0
x-wf-1-2-1-sender: http://registry.pinf.org/cadorn.org/github/firephp-libs/programs/standalone/examples/TestRunner/?lib=cadorn.org/github/firephp-libs/packages/ins...@0.0.0master1106021548
x-wf-1-2-1-2: 364|{"context":"request","target":"console\/Messages","file":"\/pinf\/programs\/com.developercompanion.reference\/packages\/lib-php-standalone\/examples\/TestRunner\/insight-devcomp\/RequestConsole-Groups.php","line":7,"lang.id":"registry.pinf.org\/cadorn.org\/github\/renderers\/packages\/php\/master"}|{"origin":{"type":"text","text":"Message","lang.type":"string"}}|
x-wf-1-1-1-3: 82||{"action":"inspectRequest","actionArgs":{"options":{"target":"console\/Groups"}}}|
x-wf-1-2-1-4: 405|{"context":"request","target":"console\/Groups","group":"Group1","group.start":true,"file":"\/pinf\/programs\/com.developercompanion.reference\/packages\/lib-php-standalone\/examples\/TestRunner\/insight-devcomp\/RequestConsole-Groups.php","line":12,"lang.id":"registry.pinf.org\/cadorn.org\/github\/renderers\/packages\/php\/master"}|{"origin":{"type":"constant","constant":"true","lang.type":"boolean"}}|
x-wf-1-2-1-5: 367|{"context":"request","target":"console\/Groups","file":"\/pinf\/programs\/com.developercompanion.reference\/packages\/lib-php-standalone\/examples\/TestRunner\/insight-devcomp\/RequestConsole-Groups.php","line":14,"lang.id":"registry.pinf.org\/cadorn.org\/github\/renderers\/packages\/php\/master"}|{"origin":{"type":"text","text":"Group Title","lang.type":"string"}}|
x-wf-1-2-1-6: 365|{"context":"request","target":"console\/Groups","file":"\/pinf\/programs\/com.developercompanion.reference\/packages\/lib-php-standalone\/examples\/TestRunner\/insight-devcomp\/RequestConsole-Groups.php","line":15,"lang.id":"registry.pinf.org\/cadorn.org\/github\/renderers\/packages\/php\/master"}|{"origin":{"type":"text","text":"Message 1","lang.type":"string"}}|
x-wf-1-2-1-7: 365|{"context":"request","target":"console\/Groups","file":"\/pinf\/programs\/com.developercompanion.reference\/packages\/lib-php-standalone\/examples\/TestRunner\/insight-devcomp\/RequestConsole-Groups.php","line":16,"lang.id":"registry.pinf.org\/cadorn.org\/github\/renderers\/packages\/php\/master"}|{"origin":{"type":"text","text":"Message 2","lang.type":"string"}}|
x-wf-1-2-1-8: 367|{"context":"request","target":"console\/Messages","file":"\/pinf\/programs\/com.developercompanion.reference\/packages\/lib-php-standalone\/examples\/TestRunner\/insight-devcomp\/RequestConsole-Groups.php","line":18,"lang.id":"registry.pinf.org\/cadorn.org\/github\/renderers\/packages\/php\/master"}|{"origin":{"type":"text","text":"Message 3","lang.type":"string"}}|
x-wf-1-2-1-9: 403|{"context":"request","target":"console\/Groups","group":"Group1","group.end":true,"file":"\/pinf\/programs\/com.developercompanion.reference\/packages\/lib-php-standalone\/examples\/TestRunner\/insight-devcomp\/RequestConsole-Groups.php","line":20,"lang.id":"registry.pinf.org\/cadorn.org\/github\/renderers\/packages\/php\/master"}|{"origin":{"type":"constant","constant":"true","lang.type":"boolean"}}|
x-wf-1-2-1-10: 244|{"context":"request","target":"console\/Groups","group":"Group2","group.expand":"Group2","lang.id":"registry.pinf.org\/cadorn.org\/github\/renderers\/packages\/php\/master"}|{"origin":{"type":"text","text":"Group 2 Title","lang.type":"string"}}|
x-wf-1-2-1-11: 429|{"context":"request","target":"console\/Groups","group":"Group2","group.expand":"Group2","group.start":true,"file":"\/pinf\/programs\/com.developercompanion.reference\/packages\/lib-php-standalone\/examples\/TestRunner\/insight-devcomp\/RequestConsole-Groups.php","line":24,"lang.id":"registry.pinf.org\/cadorn.org\/github\/renderers\/packages\/php\/master"}|{"origin":{"type":"constant","constant":"true","lang.type":"boolean"}}|
x-wf-1-2-1-12: 365|{"context":"request","target":"console\/Groups","file":"\/pinf\/programs\/com.developercompanion.reference\/packages\/lib-php-standalone\/examples\/TestRunner\/insight-devcomp\/RequestConsole-Groups.php","line":26,"lang.id":"registry.pinf.org\/cadorn.org\/github\/renderers\/packages\/php\/master"}|{"origin":{"type":"text","text":"Message 1","lang.type":"string"}}|
x-wf-1-2-1-13: 365|{"context":"request","target":"console\/Groups","file":"\/pinf\/programs\/com.developercompanion.reference\/packages\/lib-php-standalone\/examples\/TestRunner\/insight-devcomp\/RequestConsole-Groups.php","line":27,"lang.id":"registry.pinf.org\/cadorn.org\/github\/renderers\/packages\/php\/master"}|{"origin":{"type":"text","text":"Message 2","lang.type":"string"}}|
x-wf-1-2-1-14: 427|{"context":"request","target":"console\/Groups","group":"Group2","group.expand":"Group2","group.end":true,"file":"\/pinf\/programs\/com.developercompanion.reference\/packages\/lib-php-standalone\/examples\/TestRunner\/insight-devcomp\/RequestConsole-Groups.php","line":29,"lang.id":"registry.pinf.org\/cadorn.org\/github\/renderers\/packages\/php\/master"}|{"origin":{"type":"constant","constant":"true","lang.type":"boolean"}}|
x-wf-1-2-1-15: 244|{"context":"request","target":"console\/Groups","group":"Group3","group.expand":"Group3","lang.id":"registry.pinf.org\/cadorn.org\/github\/renderers\/packages\/php\/master"}|{"origin":{"type":"text","text":"Group 3 Title","lang.type":"string"}}|
x-wf-1-2-1-16: 429|{"context":"request","target":"console\/Groups","group":"Group3","group.expand":"Group3","group.start":true,"file":"\/pinf\/programs\/com.developercompanion.reference\/packages\/lib-php-standalone\/examples\/TestRunner\/insight-devcomp\/RequestConsole-Groups.php","line":33,"lang.id":"registry.pinf.org\/cadorn.org\/github\/renderers\/packages\/php\/master"}|{"origin":{"type":"constant","constant":"true","lang.type":"boolean"}}|
x-wf-1-2-1-17: 365|{"context":"request","target":"console\/Groups","file":"\/pinf\/programs\/com.developercompanion.reference\/packages\/lib-php-standalone\/examples\/TestRunner\/insight-devcomp\/RequestConsole-Groups.php","line":35,"lang.id":"registry.pinf.org\/cadorn.org\/github\/renderers\/packages\/php\/master"}|{"origin":{"type":"text","text":"Message 1","lang.type":"string"}}|
x-wf-1-2-1-18: 427|{"context":"request","target":"console\/Groups","group":"Group3","group.expand":"Group3","group.end":true,"file":"\/pinf\/programs\/com.developercompanion.reference\/packages\/lib-php-standalone\/examples\/TestRunner\/insight-devcomp\/RequestConsole-Groups.php","line":37,"lang.id":"registry.pinf.org\/cadorn.org\/github\/renderers\/packages\/php\/master"}|{"origin":{"type":"constant","constant":"true","lang.type":"boolean"}}|
x-wf-1-2-1-19: 244|{"context":"request","target":"console\/Groups","group":"Group4","group.expand":"Group4","lang.id":"registry.pinf.org\/cadorn.org\/github\/renderers\/packages\/php\/master"}|{"origin":{"type":"text","text":"Group 4 Title","lang.type":"string"}}|
x-wf-1-2-1-20: 429|{"context":"request","target":"console\/Groups","group":"Group4","group.expand":"Group4","group.start":true,"file":"\/pinf\/programs\/com.developercompanion.reference\/packages\/lib-php-standalone\/examples\/TestRunner\/insight-devcomp\/RequestConsole-Groups.php","line":40,"lang.id":"registry.pinf.org\/cadorn.org\/github\/renderers\/packages\/php\/master"}|{"origin":{"type":"constant","constant":"true","lang.type":"boolean"}}|
x-wf-1-2-1-21: 365|{"context":"request","target":"console\/Groups","file":"\/pinf\/programs\/com.developercompanion.reference\/packages\/lib-php-standalone\/examples\/TestRunner\/insight-devcomp\/RequestConsole-Groups.php","line":42,"lang.id":"registry.pinf.org\/cadorn.org\/github\/renderers\/packages\/php\/master"}|{"origin":{"type":"text","text":"Message 1","lang.type":"string"}}|
x-wf-1-2-1-22: 406|{"context":"request","target":"console\/Groups","group":"Group41","group.start":true,"file":"\/pinf\/programs\/com.developercompanion.reference\/packages\/lib-php-standalone\/examples\/TestRunner\/insight-devcomp\/RequestConsole-Groups.php","line":44,"lang.id":"registry.pinf.org\/cadorn.org\/github\/renderers\/packages\/php\/master"}|{"origin":{"type":"constant","constant":"true","lang.type":"boolean"}}|
x-wf-1-2-1-23: 367|{"context":"request","target":"console\/Groups","file":"\/pinf\/programs\/com.developercompanion.reference\/packages\/lib-php-standalone\/examples\/TestRunner\/insight-devcomp\/RequestConsole-Groups.php","line":46,"lang.id":"registry.pinf.org\/cadorn.org\/github\/renderers\/packages\/php\/master"}|{"origin":{"type":"text","text":"Group Title","lang.type":"string"}}|
x-wf-1-2-1-24: 365|{"context":"request","target":"console\/Groups","file":"\/pinf\/programs\/com.developercompanion.reference\/packages\/lib-php-standalone\/examples\/TestRunner\/insight-devcomp\/RequestConsole-Groups.php","line":47,"lang.id":"registry.pinf.org\/cadorn.org\/github\/renderers\/packages\/php\/master"}|{"origin":{"type":"text","text":"Message 1","lang.type":"string"}}|
x-wf-1-2-1-25: 365|{"context":"request","target":"console\/Groups","file":"\/pinf\/programs\/com.developercompanion.reference\/packages\/lib-php-standalone\/examples\/TestRunner\/insight-devcomp\/RequestConsole-Groups.php","line":48,"lang.id":"registry.pinf.org\/cadorn.org\/github\/renderers\/packages\/php\/master"}|{"origin":{"type":"text","text":"Message 2","lang.type":"string"}}|
x-wf-1-2-1-26: 367|{"context":"request","target":"console\/Messages","file":"\/pinf\/programs\/com.developercompanion.reference\/packages\/lib-php-standalone\/examples\/TestRunner\/insight-devcomp\/RequestConsole-Groups.php","line":50,"lang.id":"registry.pinf.org\/cadorn.org\/github\/renderers\/packages\/php\/master"}|{"origin":{"type":"text","text":"Message 3","lang.type":"string"}}|
x-wf-1-2-1-27: 404|{"context":"request","target":"console\/Groups","group":"Group41","group.end":true,"file":"\/pinf\/programs\/com.developercompanion.reference\/packages\/lib-php-standalone\/examples\/TestRunner\/insight-devcomp\/RequestConsole-Groups.php","line":52,"lang.id":"registry.pinf.org\/cadorn.org\/github\/renderers\/packages\/php\/master"}|{"origin":{"type":"constant","constant":"true","lang.type":"boolean"}}|
x-wf-1-2-1-28: 404|{"context":"request","target":"console\/Groups","group":"Group41","group.end":true,"file":"\/pinf\/programs\/com.developercompanion.reference\/packages\/lib-php-standalone\/examples\/TestRunner\/insight-devcomp\/RequestConsole-Groups.php","line":54,"lang.id":"registry.pinf.org\/cadorn.org\/github\/renderers\/packages\/php\/master"}|{"origin":{"type":"constant","constant":"true","lang.type":"boolean"}}|
x-wf-1-2-1-29: 244|{"context":"request","target":"console\/Groups","group":"Group5","group.expand":"Group5","lang.id":"registry.pinf.org\/cadorn.org\/github\/renderers\/packages\/php\/master"}|{"origin":{"type":"text","text":"Group 5 Title","lang.type":"string"}}|
x-wf-1-2-1-30: 429|{"context":"request","target":"console\/Groups","group":"Group5","group.expand":"Group5","group.start":true,"file":"\/pinf\/programs\/com.developercompanion.reference\/packages\/lib-php-standalone\/examples\/TestRunner\/insight-devcomp\/RequestConsole-Groups.php","line":56,"lang.id":"registry.pinf.org\/cadorn.org\/github\/renderers\/packages\/php\/master"}|{"origin":{"type":"constant","constant":"true","lang.type":"boolean"}}|
x-wf-1-2-1-31: 427|{"context":"request","target":"console\/Groups","group":"Group5","group.expand":"Group5","group.end":true,"file":"\/pinf\/programs\/com.developercompanion.reference\/packages\/lib-php-standalone\/examples\/TestRunner\/insight-devcomp\/RequestConsole-Groups.php","line":58,"lang.id":"registry.pinf.org\/cadorn.org\/github\/renderers\/packages\/php\/master"}|{"origin":{"type":"constant","constant":"true","lang.type":"boolean"}}|
Christoph
Wes Garland
Sep 24, 2011, 2:31:10 PM9/24/11
to gp...@googlegroups.com
The fuller context is thisif (F_ISSET(flags, NOUTF8) || getenv("GPSEE_NO_UTF8_C_STRINGS")) {JS_DestroyRuntime(JS_NewRuntime(1024));putenv((char *) "GPSEE_NO_UTF8_C_STRINGS=1");}
Jeff Johnson
Sep 24, 2011, 3:29:50 PM9/24/11
to gp...@googlegroups.com
On Sep 24, 2011, at 2:31 PM, Wes Garland wrote:
The fuller context is thisif (F_ISSET(flags, NOUTF8) || getenv("GPSEE_NO_UTF8_C_STRINGS")) {JS_DestroyRuntime(JS_NewRuntime(1024));putenv((char *) "GPSEE_NO_UTF8_C_STRINGS=1");}
Ah, I remember what this is for (more-or-less). I'm using a side-effect of JS_NewRuntime() to "lock-in" the UTF-8 settings. Funny, the exact details elude me now, I wish I had written a comment. ;) I think the idea, though, is to prevent incorrect behaviour in the event of a settings conflict, though -- preferring to throw an error instead.
I rely on vermouth on the rocks with a splash of chlorox instead of docs:
If She wishs to remind of the bug, It Will Happen.
I'm mostly compiling RPM modules against JS-1.85 now.
JS_GetStringBytes => gpsee_getStringBytes is nice, but its the 's' format
removal in JS_Convert* that's gonna be really hard to retrofit portably.
Good: I finally have some glimmer of information why I never could enumerate
properties: RPMENUMERATE_INIT_ALL was the hint I needed.
And JS "packages" as a collection of "modules" is likely going to repair
the issues I had 2 years ago with module nesting, and sharing ELF symbols
for class initiation, leading to multiple class instances and no sharing.
I should have the "BeeCrypto Calculator" (a silly RPN calculator implementing
MPI arithmetic through a JS_call) and more functional in the next week or so.
So far its just been more tedious than otherwise.
But nuking JS_GetStringBytes was a mistake imho: though I fully understand
the reasons to use jschar everywhere, ad hoc obiter dictum nuking just broke
a bunch of code for no sound reason.
So retire the ancient out to a compat library on the back 40 and keep on JIT'ing intead …
73 de Jeff trying to rescusitate unit tests next
Jeff Johnson
Sep 25, 2011, 10:18:39 PM9/25/11
to gp...@googlegroups.com
On Sep 24, 2011, at 3:29 PM, Jeff Johnson wrote:
>
> I rely on vermouth on the rocks with a splash of chlorox instead of docs:
> If She wishs to remind of the bug, It Will Happen.
>
GPSEE-0.4 at bitbuckey now builds and installs all modules using AutoFu.
There's two rather gross hacks that I've checked in:
1) The segfault I've been seeing with "./gsr -c1" is within GC on exit and can be avoided by
avoiding calling JS_MaybeGC() on the callback. Not at all a fix, but gud enuf to see what
other evils lurk.
2) (gffi) I don't know what the proper fix (or even what/why/how "standard" compliance is needed).
The current extraction failed on an a stray #define which I whacked out by supplying from the CLI
in modules/gffi/Makefile.am like this:
CPPFLAGS += \
-I$(builddir) \
-I$(srcdir) \
-I$(top_srcdir) \
-D__USE_POSIX_IMPLICITLY=1 \
$(STD_CPPFLAGS)
Otherwise gffi isn't anywhere near as bad as I thought it would be to wire up with AutoFu.
I had to change a few variables, and be a bit more careful for "make distcheck" bcause
srcdir != builddir there, and so some of the files needed $(srcdir) or $(builddir) prefixing.
But that does mean that srcdir SHOULD be RO now, and srcdir <-> builddir are cleanly
splits, so multiple builds in the same src tree are likely possible. I will check that when
I get around to "portability" checking on various platforms.
I've also wired up some of the existing tests/* with "make check", so there's lots of segfault
fodder there.
> I'm mostly compiling RPM modules against JS-1.85 now.
>
All I need atm is -lgpsee (which needs gpsee/system/vm linked in) so I haven't
looked too closely at run-time functionality yet. todo++.
I'll wait a day or two and tinker a bit more with generating gpsee_config.h, including more of
the existing tests, and doing "make check" more tersely, perhaps wire up the jsdoc generation
and starting to populate some of the portability checks in system.h and debug.h.
But the actual structural details (if you wish to use AutoFu) are now largely in place in
the bitbucket clone AFAIK.
Feedback on the changes is appreciated: if you can generate a short list or items you want,
it will be easier to prioritize andf finish up the work.
hth
73 de Jeff
Wes Garland
Sep 25, 2011, 10:47:52 PM9/25/11
to gp...@googlegroups.com
On 25 September 2011 22:18, Jeff Johnson <n3...@mac.com> wrote:
GPSEE-0.4 at bitbuckey now builds and installs all modules using AutoFu.
This is great!
There's two rather gross hacks that I've checked in:
1) The segfault I've been seeing with "./gsr -c1" is within GC on exit and can be avoided by
avoiding calling JS_MaybeGC() on the callback. Not at all a fix, but gud enuf to see what
other evils lurk.
Almost certainly a result of JS 1.8.5 changing shutdown GC semantics. Ugh. I had a really hard time with this on 1.8.2 as well.
2) (gffi) I don't know what the proper fix (or even what/why/how "standard" compliance is needed).
If I understand your query, these are the cflags which define the standard that GFFI compiles with. This might be different than the standard that the rest of GPSEE builds with. This is more important on UNIX-tm systems than Linux by a long shot; for example, on Solaris (and presumably other unices) you can select XPG4, XPG6, SUSv2 or SUSv3, and APIs might change slightly, or get entire interfaces added/removed. There's a bunch of other subtleties as well, and, in particular, SUSv3 implies C99.
But that does mean that srcdir SHOULD be RO now, and srcdir <-> builddir are cleanly
splits, so multiple builds in the same src tree are likely possible. I will check that when
I get around to "portability" checking on various platforms.
If you can keep an eye on solib paths when checking cross platform, that would be appreciated. Some of the current build mess is due to efforts trying to portably get full pathnames into the DSOs so that we can have careful/safe loading.
Feedback on the changes is appreciated: if you can generate a short list or items you want,
it will be easier to prioritize andf finish up the work.
I'll try and look at this tomorrow. I'm beat today, Christoph's loader bug is making me crazy. Either that, or I've found an "interation" between valgrind and libffi:
==3806== Command: /opt/local/gpsee/bin/gsr -f ./pinf-loader.js -- -v ./demos/HelloWorld/
==3806==
XXX calling umask
XXX avalues: 0x6746340 storage: 0x6746390 rtype_abi: 0x658afcc rvaluep: 0x67463e0 hnd: 0x67409d0
==3806== Invalid write of size 4
==3806== at 0x658ABE2: retint (in /Users/wes/hg/gpsee/libffi/builds/release/install/lib/libffi.5.dylib)
==3806== by 0x658A870: ffi_call (ffi.c:324)
==3806== by 0x654EAE2: cFunction_call (in /opt/local/gpsee/libexec/gffi.dylib)
==3806== by 0x4588E7: js::callJSFastNative(JSContext*, int (*)(JSContext*, unsigned int, long*), unsigned int, long*) (in /opt/local/gpsee/lib/libmozjs.dylib)
Grrr
Wes
==3806== Command: /opt/local/gpsee/bin/gsr -f ./pinf-loader.js -- -v ./demos/HelloWorld/
==3806==
XXX calling umask
XXX avalues: 0x6746340 storage: 0x6746390 rtype_abi: 0x658afcc rvaluep: 0x67463e0 hnd: 0x67409d0
==3806== Invalid write of size 4
==3806== at 0x658ABE2: retint (in /Users/wes/hg/gpsee/libffi/builds/release/install/lib/libffi.5.dylib)
==3806== by 0x658A870: ffi_call (ffi.c:324)
==3806== by 0x654EAE2: cFunction_call (in /opt/local/gpsee/libexec/gffi.dylib)
==3806== by 0x4588E7: js::callJSFastNative(JSContext*, int (*)(JSContext*, unsigned int, long*), unsigned int, long*) (in /opt/local/gpsee/lib/libmozjs.dylib)
Grrr
Wes
Christoph Dorn
Sep 26, 2011, 12:08:42 AM9/26/11
to gp...@googlegroups.com
Wes Garland wrote:
> I'll try and look at this tomorrow. I'm beat today, Christoph's loader
> bug is making me crazy. Either that, or I've found an "interation"
> between valgrind and libffi:
Is this regarding the segfault at the end?> I'll try and look at this tomorrow. I'm beat today, Christoph's loader
> bug is making me crazy. Either that, or I've found an "interation"
> between valgrind and libffi:
Do you need a simpler test case?
Christoph
Wes Garland
Sep 26, 2011, 8:22:13 AM9/26/11
to gp...@googlegroups.com
That might be a good idea. I found two problems by benefit of having the full loader running under instrumentation (it really exercises GPSEE!) but a small test case would be useful now.
Note to self -- the crash I'm chasing is from the GC, WillFinalize_Finalize->cFunction_closure_call->ffi.c:324; it invokes fclose() at tries to read 0xbababac6; I'm using 0xba as free-fill. Suspect offsetOf(fd) is c6-ba.
Jeff Johnson
Sep 26, 2011, 7:22:48 PM9/26/11
to gp...@googlegroups.com
On Sep 25, 2011, at 10:47 PM, Wes Garland wrote:
On 25 September 2011 22:18, Jeff Johnson <n3...@mac.com> wrote:GPSEE-0.4 at bitbuckey now builds and installs all modules using AutoFu.
This is great!
Caveat emptor: I'm still just sketching in structural changes. My sole
criteria atm is purely the build process (and trying to be minimally intrusive).
Meanwhile changing how a large project buds is going to be increasingly
intrusive.
E.g. I've now drilled GETTEXT deeply through libgpsee/gsr, essentially changing
every *printf(…) like call (not in any interesting way). All files picked up
#include "system.h"
…
#include "debug.h"
so that I can refactor the AutoFu *like HAVE_FOO_H etc) out of gpsee.h. You
know this same issue as "gpsee_config.h", which is/was a sound approach, just
a generated file with AutoFu-like (i.e. HAVE_FOO) and static inline stub functions
a bit tricky to install and use. That is the purpose of
#include "system.h"
Having spent a couple days ripping out -lmozjs185 and -lffi in order to use "system"
versions, I spent today wiring up the ability to configure with
--with-mozjs185=internal
This permits untarring js185-1.0.0.tar.gz in the top-level directory and building gpsee against
the internal tree. Because of Mozilla's stubborn Luddite addiction to autoconf213, I'm
not going to be able to *really* use RPM_CHECK_LIB(…) (where all the magic is)
to bundle the internal libmozjs.la (the libtool *.la is the missing piece in -lmozjs), but
it should help with "development", where one isn't quite ready to change the "system"
mozjs yet.
There's two rather gross hacks that I've checked in:
1) The segfault I've been seeing with "./gsr -c1" is within GC on exit and can be avoided by
avoiding calling JS_MaybeGC() on the callback. Not at all a fix, but gud enuf to see what
other evils lurk.
Almost certainly a result of JS 1.8.5 changing shutdown GC semantics. Ugh. I had a really hard time with this on 1.8.2 as well.
I can/will try to help here if necessary: it is going to take a few more days to
catch up with JS 1.8.5 internals. But RPM is deeply instrumented and the
refrcount on the private object helps shadow whatever wild Heisenbugs
JS_MaybeGC() and rooted vars introduce.
2) (gffi) I don't know what the proper fix (or even what/why/how "standard" compliance is needed).
If I understand your query, these are the cflags which define the standard that GFFI compiles with. This might be different than the standard that the rest of GPSEE builds with. This is more important on UNIX-tm systems than Linux by a long shot; for example, on Solaris (and presumably other unices) you can select XPG4, XPG6, SUSv2 or SUSv3, and APIs might change slightly, or get entire interfaces added/removed. There's a bunch of other subtleties as well, and, in particular, SUSv3 implies C99.
If you are interested in "standard" compliance, I'd suggest looking at what LinuxFoundation
LSB has evolved to with automated testing. These are run-time, not compile-time, tests
and are more effective at pinning down "standard" behavior.
But there's nothing wrong with gffi and all the usual "standard" constants to approximate
what functions SHOULD be wrapped (my sense of what you are attempting).
(aside)
You should rip out the /usr/local path if you are serious about "standard" interface
extractions. Nothing in /usr/local is "standard" by definition.
But that does mean that srcdir SHOULD be RO now, and srcdir <-> builddir are cleanly
splits, so multiple builds in the same src tree are likely possible. I will check that when
I get around to "portability" checking on various platforms.
If you can keep an eye on solib paths when checking cross platform, that would be appreciated. Some of the current build mess is due to efforts trying to portably get full pathnames into the DSOs so that we can have careful/safe loading.
solib as in rpaths? That SHOULD come for free in the AutoFu (but most of linux is ripping out
rpaths rather than using carefully as in Solaris and /opt like installs).
todo++
Feedback on the changes is appreciated: if you can generate a short list or items you want,
it will be easier to prioritize andf finish up the work.
I'll try and look at this tomorrow. I'm beat today, Christoph's loader bug is making me crazy. Either that, or I've found an "interation" between valgrind and libffi:
==3806== Command: /opt/local/gpsee/bin/gsr -f ./pinf-loader.js -- -v ./demos/HelloWorld/
==3806==
XXX calling umask
XXX avalues: 0x6746340 storage: 0x6746390 rtype_abi: 0x658afcc rvaluep: 0x67463e0 hnd: 0x67409d0
==3806== Invalid write of size 4
==3806== at 0x658ABE2: retint (in /Users/wes/hg/gpsee/libffi/builds/release/install/lib/libffi.5.dylib)
==3806== by 0x658A870: ffi_call (ffi.c:324)
==3806== by 0x654EAE2: cFunction_call (in /opt/local/gpsee/libexec/gffi.dylib)
==3806== by 0x4588E7: js::callJSFastNative(JSContext*, int (*)(JSContext*, unsigned int, long*), unsigned int, long*) (in /opt/local/gpsee/lib/libmozjs.dylib)
Grrr
No hurry.
But if you hint what you are doing to generate documentation for GPSEE, I'll drill the targets
into the Makefile. I know how to do Doxygen, but I'm unfamiliar with these tools
[jbj@wp3 gpsee-rpm]$ ls
docgen/
jazzdoc jsdoc
A simple example or even a pointer is likely enough to attempt …
73 de Jeff
Jeff Johnson
Sep 26, 2011, 11:02:30 PM9/26/11
to gp...@googlegroups.com
On Sep 26, 2011, at 7:22 PM, Jeff Johnson wrote:
>
> A simple example or even a pointer is likely enough to attempt …
>
Found what I need:
http://code.google.com/r/wes-js185/source/browse/docs.mk
todo++
73 de Jeff
Wes Garland
Sep 27, 2011, 10:10:19 AM9/27/11
to gp...@googlegroups.com
Quick notes --
Jazz Docs can be found on Google Code and runs on GPSEE. jsdoc-toolkit is a Rhino program, but I have a GPSEE port around here somewhere. I should publish it, but I eventually want to deprecate its use in favour of Jazz Docs. Jazz has fewer features, but a unique advantage (which is why it was created): It allows us to document JavaScript API from within the implementing C code.
Jazz Docs can be found on Google Code and runs on GPSEE. jsdoc-toolkit is a Rhino program, but I have a GPSEE port around here somewhere. I should publish it, but I eventually want to deprecate its use in favour of Jazz Docs. Jazz has fewer features, but a unique advantage (which is why it was created): It allows us to document JavaScript API from within the implementing C code.
Reply all
Reply to author
Forward
0 new messages