Sergey,
unicon -C invoked iconc, the unicon compiler, which produces native
machine code that can run directly without the need for the interpreter:
iconx. As Clint and I pointed out, this still in early stage on Windows and
it doesn't get built by default. I get it to build and run sometimes on
Windows but I didn't spend enough time to get it to build reliably to add
it to the default build. I'm working on improving the build system and
standardizing it so that most bits are handled automatically and in the
same way on all platforms including Windows. Stay tuned.
Cheers,
Jafar
On Tue, Jun 13, 2017 at 12:29 AM, Sergey Logichev <slogic...@yandex.ru>
wrote:
> Clint,
> If you mean that I need GCC to make unicon it's not a problem. I usually
> use mingw/mingw-w64 to build C/C++ sources on Windows. But what are rt.a
> and rt.db? First one is DLL? But for what? All works fine on Windows
> without them.
> On MS Win you have three option to build and run Unicon: CygWin, Native
> Windows and Linux Subsystem for Windows (for Win10 home/pro editions only).
> I hope that fix of "\" and "/" will be quite simple. In general sense
> Windows port is workable on 100%. If some inconsistencies will be found in
> the future - it's only good strategically. Unicon is pretty flexible, fast
> and excellent already. And will be better I hope!
> By the way, since last year in Unicon sources persists one buggy
> definition in gdbm/systems.h at line #165:
> #define TRUNCATE(dbf) close( open (dbf->name, O_RDWR|O_TRUNC, mode));
> Trailing semicolon (;) produces weird consequences during compilation
> process and prevent successful build. I think that ; added by some strange
> case.
> Sincerely,
> Sergey
>
>
> 13.06.2017, 08:06, "Jeffery, Clint (jeffe...@uidaho.edu)" <
> jeffe...@uidaho.edu>:
>
> Sergey
>
> Your \ and / issue points out rather simply that unicon -C hasn't fully
> been ported to Windows yet, and even if we fix this little issue and get it
> to run, you will need a C compiler for the generated code, and someone will
> have to build the runtime system rt.a and rt.db on Windows. Maybe most of
> the port has been done awhile back by Shea, but it is not in the public
> Unicon binaries yet. I'll check on all this and report back.
>
> Clint
>
> *Sent from my LG G6, an AT&T 4G LTE smartphone*
>
> ------ Original message------
> *From: *Sergey Logichev
> *Date: *Tue, Jun 13, 2017 12:55 AM
> *To: *Contact - clint.jeff...@gmail.com;
> *Cc: *Unicon group;
> *Subject:*Re: [Unicon-group] unicon -C ==> -fs tweak
>
> Clint,
>
> Now I understand. I suppose that mix of "\" and "/" is produced by "../"
> somewhere internally in unicon. To avoid same problem (as I use my code on
> Windows and Unix transparently) I define path-separator character. "\" for
> Windows and "/" for Unix and all is fine!
> Thank you for reference to utr11, it's quite informative and no more
> questions.
> Thanks!
> Sergey
>
> 13.06.2017, 07:43, "Clinton Jeffery" <clint.jeff...@gmail.com>:
>
> Dear Sergey,
>
> I agree that "ca-add-link" ... "not ready" is not a very good message. It
> is easy to see the spot in the code (uni/unicon/ca.icn) where the error
> message is emitted. It is less transparent what is the cause, and what is
> the fix. One possibility is the mixture of \ and / as path separators seen
> in the message.
>
> The error message occurs when a "table of all the ucode files", uftbl,
> does not have a table entry for the requested file, in this case
> c:\\work\\unicon\\bin\\../ipl/gprocs\\graphics.icn
>
> I can imagine the table having that path to graphics.icn inserted, but all
> with \\ or all with /. Unlike a C open() command, a table lookup will not
> accept either character as equivalent. I will need to experiment on a
> Windows machine to try and reproduce your bug and find out if it has to do
> with \\ vs. / or something else, unless you or someone else beats me to it.
> If it is \ and / mixing that is the problem, it should be pretty easy to
> fix.
>
> In answer to your other question, I agree that unicon -help is swell. The
> man page for unicon is http://unicon.org/utr/utr11.html and if the -help
> output or the utr11.html are unclear, we want to know about it so we can
> make additions and corrections to them.
>
> Cheers,
> Clint
>
> On Tue, Jun 13, 2017 at 12:24 AM, Sergey Logichev <slogic...@yandex.ru>
> wrote:
>
> Hello Clint,
>
> Unfortunately, I didn't managed to build my lovely program with -C option.
> I got the following (that's the end of long output):
> Parsing xm.icn: ..............................
> ............................................
> Parsing sort.icn: .....
> Parsing process.icn: ..............................
> ........................
> Parsing options.icn: .
> Parsing regexp.icn: ....................................
> Parsing futils.icn: .................
> Parsing escape.icn: ...
> Parsing asort.icn: ............
> Parsing xmprocs.icn: ...............
> Parsing unicodes.icn: ....................
> Parsing htmlutils.icn: ...........
> Parsing graphprocs.icn: ........
> Parsing c:\work\unicon\bin\../ipl/gprocs\graphics.icn:
> .........ca-add-link: "c:\\work\\unicon\\bin\\../ipl/gprocs\\graphics.icn"
> not ready.
>
> I don't understand what does it mean - "not ready". Could you please
> dechipher this message. I have "link graphics" in my code and I sure that
> it is already compiled. Without option -C all is built fine.
> As for option -fs, in my humble opinion it should be always. As I
> understand if I have some procedures in code which are not called they will
> be removed during compilation as redundant. But it's not my case, I need
> such procedures definitly, as my program interprets and runs "on-the-fly"
> scripts written in simplified Icon/Unicon and these scripts can include any
> available procedural calls. It's slightly extended version of an approach
> firstly implemented by Stephen Wampler in IPL's icalc.icn.
> Maybe you can advice some more advanced approach to me? I will be very
> appreciated to you.
> Sincerely,
> Sergey Logichev
>
> PS. I was very happy to see option -help for uncion! That's really great!
> Does it exist more complete description of each option in docs?
>
> 12.06.2017, 20:47, "Clinton Jeffery" <clint.jeff...@gmail.com>:
>
> Dear Uniconers,
>
> Lots of exciting work is getting done by the Unicon community right now.
> I hope you are having a blast.
>
> Just to let you know: after several of you reported programs that would
> run under unicon -C but only if the -fs option was used, I went ahead and
> asked Ken Walker if there was any reason not to turn -fs on all the time,
> other than the slightly larger code size it would entail. He indicated that
> actually using string invocation (the feature -fs was written to support)
> reduces the effectiveness of type inferencing, but that leaving -fs on was
> fine if we don't mind the code size.
>
> So, I turned on -fs automatically if -C is used in unicon, in our svn
> repository. It allows a number of Unicon programs to compile or run
> correctly that otherwise do not. But, if you encounter any problems due to
> it, I want to hear about them and could change the default back if it has
> any really bad side effects. If you are using a binary distribution or
> building from a .zip this change won't affect you for now.
>
> Cheers,
> Clint
>
> ,
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ,
>
> _______________________________________________
> Unicon-group mailing list
> Unicon-group@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/unicon-group
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Unicon-group mailing list
> Unicon-group@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/unicon-group
>
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Unicon-group mailing list
Unicon-group@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/unicon-group
