On Thursday 05 Jan 2012 01:21:48 Jean-Louis Faucher wrote:
Hi Jean-Louis,
> > There is a segmentation fault after re-tokenisation, but it doesn't kill
> > rxapi.
>
> I'm curious to know : how often do you have crashes when using your build
> ? I re-tested today under Puppy, running functional-test.rex. When the
> modified rxapi is started as a daemon, I have a crash on one of the two
> executions.
>
same here, segmentation fault every other execution.
my original interpretation is wrong.
> A preliminary remark : given the experimental aspect of my sandbox, I had
> in mind a "no install" delivery for preview, rather than a "real" install.
> So I would be interested to know if you have specific reasons to make a rpm
> (I'm just curious :-)
1) I'm an amateur and don't know better.
Not knowing where to start I just did "make rpm" and follwed up on the errors.
2) rpm protects me from myself, i.e. ruining an installation by manual editing
as root. rpm manages dependencies, and it is easy to switch rexx versions:
rpm -e <old.rpm> && rpm -i <new.rpm>
> I have a question about this comment in your script :
> *Patches install also trunk/samples/native.api; they do not install new
> header files.*
> Normally, I'm in sync with main/trunk, so it means that samples/native.api
> are not part of the official delivery, and should be ? I did not take time
> to verify... The files are listed below.
samples/native.api are not part of the official linux delivery.
I thought they were cross-platform and should be included, but see
http://sourceforge.net/support/tracker.php?aid=3469948
I just gave it a try and it doesn't compile straight away.
uli@ulmo:~/oorexx/sandbox/jlf/trunk/samples/native.api/call.example> cp
Makefile.linux Makefile
uli@ulmo:~/oorexx/sandbox/jlf/trunk/samples/native.api/call.example> make
gcc -c -fPIC -o runRexxProgram.o runRexxProgram.cpp
runRexxProgram.cpp: In function ‘int main(int, char**)’:
runRexxProgram.cpp:100:44: error: ‘strcmp’ was not declared in this scope
make: *** [runRexxProgram.o] Error 1
> And which are these new header files not installed ?
$(m17nHeaders)
$(m17nCharsetHeaders)
$(m17nEncodingHeaders)
The makefile contains a few header files which are installed (like
rexxplatformdefs.h) but most are not. Not knowing in which group to place the
new headers, I left them with the majority (uninstalled) and put a warning.
>
> I applied the patches and made a make install (I don't have rpmbuild).
> Then, I made a diff between the previous tree file, and the new one. The
> new files are listed below, and that brings some questions :-)
>
> > ooRexx-jlf/bin/concurrency
> > ooRexx-jlf/bin/concurrency/activity.cls
...
> All the files above are more library files than binary files. I understand
> that putting them in bin let find them automatically, because the PATH
> includes the bin directory. But see below, there are also some library
> files that you put under share/ooRexx.
>
> > ooRexx-jlf/share/ooRexx/native.api
> > ooRexx-jlf/share/ooRexx/native.api/call.example
...
I don't have a strong opinion and to start with I wasn't sure whether it is
just an example or for general use. A symlink to /usr/bin could be set.
> Assuming we start thinking about a standard library for ooRexx, what should
> be the file organization ? I did not take time to study Python and Ruby
> libraries, there are probably some common practices.
rpm -ql ooRexx
to see how *.rexx *.cls and executables ae installed: the structure is flat,
there is no notion of packages.
this has the advantage that path elements are not hardcoded in the sources,
so classes can be relocated or regrouped into new packeages without breaking
classes.
While path elements are hardcoded in the scripts and classes, a flat
installation is not possible.
> See my previous question about native api files.
>
> > ooRexx-jlf/share/ooRexx/pipeline
> > ooRexx-jlf/share/ooRexx/pipeline/pipe.rex
>
> Files above are library files. "share/ooRexx" seems the good place to
> deliver them. I assume this directory is added to PATH by the installer ?
I think it is safer to provide *.cls files, because ::requires is checked when
the script starts and independent of program flow.
I haven't considered whether they are meant for interactive command line.
I have to give the subject more thought.
Cheers, Uli
>
> > ooRexx-jlf/share/ooRexx/_samples
> > ooRexx-jlf/share/ooRexx/_samples/doers-benchmark.rex
> > ooRexx-jlf/share/ooRexx/_samples/doers-info.rex
> > ooRexx-jlf/share/ooRexx/_samples/doers-samples.rex
> > ooRexx-jlf/share/ooRexx/_samples/doers-stress.rex
> > ooRexx-jlf/share/ooRexx/_samples/functional-test.rex
> > ooRexx-jlf/share/ooRexx/_samples/pipe_extension_test.rex
>
> Files above are samples files. No remark, except maybe that we have some
> sample files directly under "share/ooRexx". Maybe we need a proper
> distinction between library files and samples files ?
>
> > ooRexx-jlf/share/ooRexx/trace
> > ooRexx-jlf/share/ooRexx/trace/tracer.rex
> > ooRexx-jlf/share/ooRexx/oorexxshell.rex
>
> Files above are utility scripts, so candidate to go in bin, unless there is
> also a common practice (other than bin) to deliver utility scripts like
> that ?
>
> > ooRexx-jlf/share/ooRexx/readme.txt
>
> Jean-Louis
------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual
desktops for less than the cost of PCs and save 60% on VDI infrastructure
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
_______________________________________________
Oorexx-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
