questions about ArrayDyn, Functor, Object, Any
bkerin opened this issue · comments
I've been working on adding gcompose/gcomposen implementations back in to Functor such that the ex01 can work again. My stuff works ok with the existing ComposFun data type which just has an OBJ[], but I thought it might be nice to use two-sided growth array instead to flattening of composed Functors could be fast at eval-time and not involve potentially big copies at compose-time. I see ArrayDyn already has an implementation for this.
There are a few issues though. Array hold Object, and Functor are explicitly not Objects. I'm not entirely clear why not? Or Array could hold Any instead? The only manifest difference I see between Any and Object is that the former doesn't support new* methods, but perhaps there is some conceptual difference intended as well?
I did get this working before notiicing the Any/Object issue (I guess the auto constructor is somehow avoiding the issue), so it seems like it could work in principle at least for this case, and it's a bit sad that Functor's aren't Objects or Arrays dont store Objects or something:
OBJ ftor_array = aArray(t3f, t2f, t5f);
OBJ view = aArrayView(ftor_array, aSlice(1, gsize(ftor_array)-1, 1));
OBJ t3t2t5f = gcomposen(ftor_array);
@bkerin 👍 Thanks for the steady work through the COS code.
I implemented alternative build scripts for cosgen, cosprp, and cossym using perl instead of unix commands and shell scripting in order to be able to build COS on windows (or anything with perl installed).
Related to this topic, I was unable to run the example program in CosStd/examples/ex01/ and wondered if you had had any success building and running that example? The output I get on my cygwin/win7 system looks like this:
% ./cos-ex01_ds.exe
*** functional sum (repeat + eval)
COS-Trace[7200]: (src/AutoRelease.c,291): -> ginitialize(pmAutoRelease)
COS-Trace[7200]: (src/AutoRelease.c,258): -> ginit(AutoRelease)
COS-Trace[7200]: (src/AutoRelease.c,266): <- ginit
COS-Trace[7200]: (src/AutoRelease.c,303): <- ginitialize
COS-Trace[7200]: (src/Object.c,37): -> gnew(pmAutoRelease)
COS-Trace[7200]: (src/Any.c,44): -> galloc(pmAutoRelease)
COS-Trace[7200]: (src/Any.c,53): <- galloc
COS-Trace[7200]: (src/AutoRelease.c,258): -> ginit(AutoRelease)
COS-Trace[7200]: (src/AutoRelease.c,266): <- ginit
COS-Trace[7200]: (src/Object.c,38): <- gnew
COS-Trace[7200]: (src/AutoRelease.c,194): -> gautoRelease(FunExpr2)
COS-Trace[7200]: (src/Any.c,136): -> gunrecognizedMessage1(FunExpr2)
COS-Trace[7200]: (src/Object.c,57): -> gnewWithStr(pmExBadMessage)
COS-Trace[7200]: (src/Any.c,44): -> galloc(pmExBadMessage)
COS-Trace[7200]: (src/Any.c,53): <- galloc
COS-Trace[7200]: (src/Exception.c,82): -> ginitWithStr(ExBadMessage)
COS-Trace[7200]: (src/Exception.c,85): <- ginitWithStr
COS-Trace[7200]: (src/Object.c,58): <- gnewWithStr
COS-Trace[7200]: (src/cos_exception.c,206): -> gthrow(ExBadMessage)
COS-Trace[7200]: (src/Exception.c,104): -> gstr(ExBadMessage)
COS-Trace[7200]: (src/Exception.c,109): <- gstr
COS-Warn [7200]: exiting with uncaught exception ExBadMessage 'gcopy(FunExpr2)' thrown at (src/Any.c:140)
COS-Trace[7200]: (src/AutoRelease.c,305): -> gdeinitialize(pmAutoRelease)
COS-Trace[7200]: (src/AutoRelease.c,269): -> gdeinit(AutoRelease)
COS-Trace[7200]: (src/AutoRelease.c,245): -> grelease(AutoRelease)
COS-Trace[7200]: (src/AutoRelease.c,252): -> gsize(AutoRelease)
COS-Trace[7200]: (src/AutoRelease.c,253): <- gsize
COS-Trace[7200]: (src/AutoRelease.c,246): destroying pool at 0x600052d08 [0 objects]
COS-Trace[7200]: (src/AutoRelease.c,269): -> gdeinit(AutoRelease)
COS-Trace[7200]: (src/AutoRelease.c,286): <- gdeinit
COS-Trace[7200]: (src/Any.c,74): -> gdealloc(AutoRelease)
COS-Trace[7200]: (src/Any.c,76): <- gdealloc
COS-Trace[7200]: (src/AutoRelease.c,248): <- grelease
COS-Trace[7200]: (src/AutoRelease.c,286): <- gdeinit
COS-Trace[7200]: (src/AutoRelease.c,313): <- gdeinitialize
COS-Trace[7200]: (src/cos_exception.c,229): -> gdeinitialize(pmException)
COS-Trace[7200]: (src/cos_exception.c,234): <- gdeinitializeI tried looking at the generated code but was not able to determine the problem and my C skills are not sufficient to debug or analyze further.
ASIDE: I did work my way through the very elegant CPP macros used to implement COS and the provided multi-methods and open architecture. My plan was to use COS to provide a powerful, portable object computation capability with a C FFI for interoperability with just about everything.
Apologies but I cannot turn off the block quote after the pasted COS-Trace output.
Thx, COS is some of the prettiest code I've seen and I want to get it fully working again.
I haven't seen exactly the trace you show below, but I believe it's related to the fact that ex01 was never updated following a (very healthy and desirable looking) refactor of Functor. The placeholder interface changed and e.g.
grep -r 'defmethod.*gcompose' shows that gcomposen has no implementations at the moment. Basically ComposeFun IterateFun and MsgExpr are unimplemented. I have working implementations of the first two, but am hoping for some advice from Laurent on how to proceed (above questions) before working on it more.
And looking back at the question I see I typod, what I wonder is why Array can't store Any (it currently does Object).
Ok. What I have added a generic
defgeneric(U32, gfreeVarCount, Functor);
and allows compositions to have multiple free vars at pipeline entrance, one elsewhere. I confess I'm slightly attached to my implementation and would be a tiny bit sad if it got redone. Maybe I'll put it up as a fork on Fri., though there are many things undecided in it.
Hello Laurent,
I have not seen any activity on this in a while. Is there still some interest on your end or should I just proceed in a fork?
Thanks,
Britton
When I will have some time, I will review CosStd which looks overdesigned for the provided classes, including functors. I will also introduce tagged NaN to simplify classes that contain value types (primitive types).
I really like the COS concept and project as well. I was able to compile COS and
managed some build process modifications to replace posix shell machinery with
perl to improve cross-platform portability.
Unfortunately, I was not able to get some of the more advanced functionality
working and I wasn't able to debug the problem---or even understand how to
start diagnosing things.
The latest master from git does "make" but the "make tests" reports an error
output like this:
*** Running [release] testCosBase.exe
/bin/sh: line 1: export: `=$:../CYGWIN_NT-10.0/lib:CYGWIN_NT-10.0/lib': not a valid identifier
/bin/sh: line 2: CYGWIN_NT-10.0/bin/testCosBase.exe: No such file or directory
make[2]: *** [../include/cos/mak/program:72: release.run] Error 127
make[1]: *** [include/cos/mak/common:58: tests.do] Error 2
make: *** [CosBase/include/cos/mak/common:63: CosBase.tests] Error 2
which looks like a familiar error from when I last poked around with COS.
That said, I've moved from perl and Perl Data Language to julia for my
software and algorithms development. It would be interesting to be
able to use/call COS from Julia via the C FFI. I've wondered how the
performance of COS would stack up against Julia especially as regards
dynamic dispatch.
I really like the COS concept and project as well. I was able to compile COS and managed some build process modifications to replace posix shell machinery with perl to improve cross-platform portability.
This is a good thing, if it works fine and you make a PR, I will add the perl tools. I agree that using shell was slow complicated and not portable...
Unfortunately, I was not able to get some of the more advanced functionality working and I wasn't able to debug the problem---or even understand how to start diagnosing things.
Can you say more about these functionalities?
The latest master from git does "make" but the "make tests" reports an error output like this:
*** Running [release] testCosBase.exe
/bin/sh: line 1: export: `=$:../CYGWIN_NT-10.0/lib:CYGWIN_NT-10.0/lib': not a valid identifier
/bin/sh: line 2: CYGWIN_NT-10.0/bin/testCosBase.exe: No such file or directory
make[2]: *** [../include/cos/mak/program:72: release.run] Error 127
make[1]: *** [include/cos/mak/common:58: tests.do] Error 2
make: *** [CosBase/include/cos/mak/common:63: CosBase.tests] Error 2which looks like a familiar error from when I last poked around with COS.
Sorry, but I cannot reproduce the problem on my mac, and I don't have access to a Windows/Cygwin/MSys2 VM anymore.
That said, I've moved from perl and Perl Data Language to julia for my software and algorithms development. It would be interesting to be able to use/call COS from Julia via the C FFI. I've wondered how the performance of COS would stack up against Julia, especially as regards dynamic dispatch.
I don't know how Julia is performing using dynamic dispatch. Calling COS dispatch from Julia is not possible because everything is inlined for performance reasons and built at runtime, including dispatch caches.
Calling a given method is not easy either, because all the arguments and the returned values are packed into a single local data structure by the generics, this is why message forwarding is as fast as message dispatch and doesn't have limitations on returned types as in Objective-C.
I would love to see this project as production ready. I would have loved to be able to introduce it to other projects if that was the case. Sorry if this is not the right place for this comment.
As a note of interest I use the preprocessor part in embedded systems right now (with the only modification being all of it put in one header). It seemed like the best and cleanest such setup available. Britton
I am surprised by this use of COS, why don't you use a more complete and advanced preprocessor C99 library like chaos-pp from Paul Mensonides or the more recent P99 from Jens Gustedt?