I will also add that AFAIK Unicon -C is not yet fully tested/functional on
Windows. It is not yet included in the Windows binary distribution for that
reason.
--Jafar
On Mon, Jun 12, 2017 at 11:55 PM, Sergey Logichev <slogic...@yandex.ru>
wrote:
> 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
