The current COS build process requires GNU make 3.80 or above. This is problematic for platforms that don't have a "friendly" posix-ish development environment like MS windows. The lack of a standard shell for windows introduces incompatibilities in GNU make implementations due to the non-posix implementations.

After studying the build process and files in include/cos/mak I've determined that the basics of the build process appear to be:

1. run cosgen to produce XXX_gens.c if generics are being defined, add XXX_gens.o to OBJECTS
2. run cosprp to produce XXX_prps.c if properties are being defined, add XXX_prps.o to OBJECTS
3. after compiling all the files, run cossym to produce XXX_syms.c to compile and link with OBJECTS

It seems that a coscc script might be written to implement this process without requiring GNU make. The GNU make build process could use this script to run the build. It could also be used from other makes to build software using COS.

It took me some time to realize why this program seg faults:

OBJ anint = aInt(42);
fprintf (stderr, "int: %i\n", gint(anint));

This one is annoying because of it gets masked by other code which does cos_init(). Always doing an explicit cos_init() is the safe thing but the OOPSLA paper doesn't mention this and the examples don't show it. This

It seems to me that in debug mode (or something) the gint() (and the like) might be able to trigger a
check of cos_symbol.c/init_done static (through an interface function). Or maybe that
would be regarded as too slow even for debug mode, I don't know.

This code does give a nice explanation:

OBJ anint = aInt(42);
cos_init();
fprintf (stderr, "int: %i\n", gint(anint));

COS says:

COS-Abort[8876]: invalid class id 671088640 - dynamic object already destroyed or automatic object used before COS initialization

I'm really just going through and documenting all the trip-ups I make as I get started
with COS.

Stray underscore in the param-list syntax:

par_am-list:
param-decl
param-list , param-decl

It appears the problem is in the # rules for running shared program (helper)
and the creation of the appropriate environment to run the tests being compiled.
Will continue to track down the issue but opening this ticket to track the problem.

There is no Bash shell like MSYS2 so it's a separate issue from MSYS2: #42

https://winlibs.com/

https://github.com/niXman/mingw-builds-binaries/releases

https://github.com/mstorsjo/llvm-mingw/releases

http://www.smorgasbordet.com/pellesc/

It's still nice to be able to see e.g.:

*** Running [debug] cos-props_d

when SHOW=yes, changing it to output comment prefix keeps the output true (i.e. paste-and-buildable).

original, ends up hiding step descriptions when SHOW=yes (annoying):

#E := $(if $(call eq,$(SHOW),yes),@ #,@ echo)

If SHOW is yes start $E lines with comment prefix, otherwise just plain @ echo:

E := $(if $(call eq,$(SHOW),yes),@ echo '#',@ echo)

I think just putting such lines as comments would work as well and make $E unneeded so maybe there is some reason this was done that I'm not aware of.

For example, CYGWIN_NT is enough for detection of Cygwin.

Related issues: #37 #38

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);

README said MSYS2 was a tested platform:

But the fact is it doesn't work on MSYS2! It doesn't work on any Shells of MSYS2!

On MSYS2 MSYS Shell:

CosBase/include/cos/prologue:113: CosBase/include/cos/cfg/MSYS_NT-6.3-9600: No such file or directory
make: *** No rule to make target 'CosBase/include/cos/cfg/MSYS_NT-6.3-9600'.  Stop.

On MSYS2 MINGW64 Shell:

CosBase/include/cos/prologue:113: CosBase/include/cos/cfg/MINGW64_NT-6.3-9600: No such file or directory
make: *** No rule to make target 'CosBase/include/cos/cfg/MINGW64_NT-6.3-9600'.  Stop.

Github Discussions is a new feature of Github. It's a support forums for users to ask questions. The traditional Issues should be for reporting bugs only. Please consider turning on Github Discussions. Thank you.

*** functional sum (repeat + eval)
COS-Info [23583]: exiting with uncaught exception ExBadMessage 'gcopy(FunExpr2)' thrown at (src/Any.c:140)

I'm interested in using and/or contributing to COS but need a portable framework including windows. Is the problem with a windows build a requirement of the library itself or is it due to the build process. If the latter, there is MSYS for gnu-ish build and shell tools and gcc is available for windows as well.

uname -s on MSYS2 MSYS Shell on my system is MSYS_NT-6.3-9600. Only the part MSYS_NT should be considered and used as the key to detect MSYS2 MSYS. The later part is Windows versions (that would change from system to system).

Note: MSYS2 MSYS is a fork of Cygwin. MSYS2 project provided several Shells, each Shell is a separate environment.

Your research papers are good reference sources but they don't provide the complete picture. They have overlapped content with a lot of implementation details that normal users don't need to care about. If all of them are drafts then which is the final edition? People need a complete manual to jump straight into working.

A wish, not really an issue - I am very tempted to use COS but find port part tedious - what about aleviating this by using cmake to generate makefile and configuration files, and to use tinycthreads for the threads capability ?

https://github.com/LADSoft/OrangeC

It's not as simple as copying the config for Cygwin and adapt it for MSYS2. I tried, but for unknown reasons, it still said it can't find the config files for MSYS2 even though they are right there, next to other config files for other systems. I also found there is no Windows support at all (I mean MSVC because MSVC is the official compiler for Windows), so far I only see Unix or Unix emumation (Cygwin). I examined the config file for Cygwin and I found:

#
# system specific
#
SYSFLAGS    := -DOSNAME=$(OSNAME) \
               -D_XOPEN_SOURCE=500 -D_REENTRANT -D_THREAD_SAFE \
               -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE

Defining -DOSNAME=$(OSNAME) directly like that means there is hard coded adaptions for $(OSNAME) on source code level. So it's definitely not as simple as copying the config for Cygwin and adapt it for MSYS2 could make it work on MSYS2.

Fix the link at the top of the github project home page:

http://ldeniau.web.cern.ch/ldeniau/cos.html

Free compiler (32 bit only):

https://www.embarcadero.com/free-tools/ccompiler

C++ Builder Community Edition:

https://www.embarcadero.com/products/cbuilder/starter

Try to build this project on Linux with GCC 10 and make fails with:
Linux/release/CosBase_prps.o:(.bss+0x8): multiple definition of `cos_method_trace

GCC 10 defaults to -fno-common which is what is producing this error.
as described here:
https://gcc.gnu.org/gcc-10/porting_to.html#common

I gather emscripten doesn't work well with C code that contains many function pointers casts (and such are not actually defined behavior in C).

Does COS target emscripten ok?

The BINEXT is used to indicate a "binary executable" file in the usages I am familiar with. It appears that in the build process, the utility scripts cosgen, cosprp, and cossym are copied to files with BINEXT as the extension. This doesn't work because those files are not binary executables.

https://github.com/skeeto/w64devkit

w64devkit is based on busybox-w32: https://github.com/rmyorston/busybox-w32

uname -s on busybox-w32 will report Windows_NT, it's a fixed string on Windows so it's easier to support than the dynamic result of uname -s on Cygwin/MSYS2 as they also incorporate Windows version into the strings (so uname -s on MSYS2/Windows 7 will different from uname -s on MSYS2/Windows 10).

COS/CosBase/examples/ex01/File.c contains:

defmethod(OBJ, ginitWithStr, File, (STR)str)
self->file = str ? fopen(str,"r+") : stdout;
if (!self->file)
test_errno(); // THROW

retmethod(_1);
endmethod

Using 0 caused me some confusion. Seems like it should get "stdout" in the call as well to be clear.
Part of the confusion comes because using 0 causes stdout to get closed on grelease(strm), which causes e.g. printf() statement after this to show nothing.

This is an issue because the examples in CosBase and CosStd are the first things people are likely to try playing with in COS, so getting them as unsurprising as possible seems worthwhile.

$ make 2>&1 | grep --perl-regexp --only-matching '[-W.=?.]' | sort | uniq --count
7 [-Wimplicit-fallthrough=]
30 [-Wunused-const-variable=]
15984 [-Wunused-local-typedefs]

All the tests in make tests succeed and I guess these are probably warnings that have crept in with recent additions to -Wall in gcc.

For the last of these at least it seems likely that adding -Wno-usused-local-typedefs would be the solution.

Currently this file contains:

incdirs := ../../../CosBase/include ../../include .
libdirs := ../../../CosBase/$(OSNAME)/lib ../../$(OSNAME)/lib

It might be nice if it did things more like the tests in CosStd instead:

incdirs := $(foreach m,$(moddeps),../../../$(m)/include) .
libdirs := $(foreach m,$(moddeps),../../../$(m)/$(OSNAME)/lib)

As this would show a general mechanism for pulling in modules. Or maybe that isn't the preferred way for user-developed modules.

uname -s on MSYS2 MINGW64 Shell on my system is MINGW64_NT-6.3-9600. Only the part MINGW64_NT should be considered and used as the key to detect MSYS2 MINGW64. The later part is Windows versions (that would change from system to system).

Note: MSYS2 MINGW64 targets native Windows without POSIX compatibility, unlike MSYS2 MSYS. MSYS2 project provided several Shells, each Shell is a separate environment.

The comments at the top of CosBase/include/cos/cos/method.h include:

   method-definition:
     defmethod( generic-specifier )
       method-statement
     endmethod

Where generic-specifier presumably refers to CosBase/include/cos/cos/generic.h where there is this:

   generic-specifier:
     return-type , generic-def , param-list

   generic-def:
     generic-name
     ( class-name ) generic-name

But when generic names appear in method definitions they specify around methods, not class names (and the word following the tuple is presumably being interpreted as a tag as mentioned in the OOPSLA paper). As in CosStd/src/File.c:

defmethod(void, (ginitialize)StdioInit, Any)`

This looks like a case where the grammar in the user notes got over-factored, as the paper seems more correct.

I'll be happy to phrase all reports like this as pull requests if you like, but I'd hate to make things worse and I'm not yet confident of the correct fixes for problems like this one (where I don't know what tag names are for exactly).

I guess the most simple fix would be to add another entry to this list that appears in method.h:

   where in the context of methods:
     - the param-name_opt in param-decl can be omitted for unused argument.
     - the last param-decl must be (va_list)va for variadic generics.

But it's already somewhat confusing and it might be better to just write out in method.h the full grammar for the flavor of generic-specifier accepted in defmethod() context.

looks like this was done in the individual Makefile but then it got moved into cos/mak/default like so:

 DEFGENS   = $(wildcard $(defgens))

This is sort of unfortunate because then a typo in a file name in defgens := in a project Makefile
causes a silent failure to run cosgen at all. From commit 2a8c83f
it looks like at some point projects just did $(wildcard) themselves if they wanted it and IMO that's a better way to go, as surprise application of wildcard to constant expressions is error-prone. I guess since it was once done its probably still possible and late $(wildcard) on simply expanded variable content is not required for other reasons. It works ok for me so far for my simple tests anyway.

From gitk it looks like they are removed but there are still a couple uses/mentions floating around. I'm not sure if Vector_lzy.c isn't build or what. Anyway here are the mentions:

$ pwd
/home/bkerin/tmp/COS
$ grep 'gautoDelete' -r *
CHANGELOG: - gdelete and gautoDelete added (for semi-GC)
CosStd/src/tmpl/Vector_lzy.c: retmethod( gautoDelete(VALOBJ(vec->value[ivec->stride])) );
$ grep 'Delete' -r *
CHANGELOG: - gdelete and gautoDelete added (for semi-GC)
CosStd/src/tmpl/Vector_lzy.c: retmethod( gautoDelete(VALOBJ(vec->value[ivec->stride])) );
CosStd/include/cos/gen/floatop.h: new autoDelete object resulting from the promotion/coercion of _1
CosStd/include/cos/gen/numop.h: new autoDelete object resulting from the promotion/coercion of _1
$

AFAICT, the COS build process is a combination of shell scripts run to extract needed information from the files and to generate the needed additions along with some Makefile magic which exists to correctly compile and link the resulting code. The GNU libtool is a shell script that was designed with the goal of hiding the mess of correctly building and linking files on multiple platforms. Given that you already require a shell, it might make sense to move to libtool as that already enables building and linking programs and libraries both static and dynamic on posix, windows, and cygwin.

In CosBase/include/cos/cos/method.h:

method-definition:
defmethod( generic-specifier )
method-statement
endmethod

method-statement:
statement
statement-with-contract

This looks wrong because multiple statements are allowed, the OOPSLA paper version looks more right.

The comment for the first of these two is wrong. It should say 'using space as separator' or maybe using empty string as separator or something.

// flatten tuple T to sequence using s as separator, i.e. (a,b,c) -> a b c
#define COS_PP_SEP(T)
COS_PP_FOLDL(T,,COS_PP_PAIR)

// flatten tuple T to sequence using s as separator, i.e. (a,b,c),; -> a ; b ; c
#define COS_PP_SEPWITH(T,s)
COS_PP_IF(COS_PP_2ARGS(COS_PP_ID T))(
COS_PP_ARG1 T COS_PP_SEP(
COS_PP_MAP2((COS_PP_REST T),(COS_PP_DUPSEQ_N(s)),COS_PP_SWAP)),
COS_PP_ID T)

There were 12 FAILs in the XRange tests which appear to
be the result of floating point error in calculating the number
of counts inthe range. 0.1 is not exact in floating point.
In XRange.h the code used DBL_EPSILON. I edited to use
FLT_EPSILON instead and all tests PASS. I'm not familiar
enough with the COS code base yet to determine if thios is the
correct fix.