Re: [Unicon-group] unicon -C ==> -fs tweak

[Sergey Logichev]

Brian,That's right - say about Unicon only truth and nothing else! And never hurry to make fast conclusion. That are the main principles, of course.Pi2 is a great thing and currently supports a lot of different OSes. Guys even found a way to emulate x86 architecture on this tiny board!There is IoT version of Windows10 for this great platform from MS itselves. But you prefere Unix, sorry! By the way, Unicon works finely on Pi.I see, you have unbelievable experience - programming of microchips and COBOL for mainframes. I take off my hat...I don't like VC and GUI, my choice is mingw and mingw-w64, which are the true ports of gcc on Windows. Hope I will make out. As Russian proverb talks -"patience and work will grind out all things".As for xmarkup, I hope it can be useful for you in some cases. Currently I am preparing a new update of it (bug fixes with fresh gcc and Unicon builds).Thanks for warm words about it.I slightly changed xmarkup graphics (added colors for individual bars of hist) a got the following colourful viz.Sergey 13.06.2017, 16:07, "Brian Tiffin" :Sergey Logichev wrote: So, it's unfortuanately just a misprint: "Unicon -load 0,04 ... C 0,05"? One percent slower it is also great!Not really a misprint as it turns out; I just updated the doc, but nowI see what I did on third look. The loadfunc version of the gcc C codeuses -O3, so it does actually time at 0.04, but it's kinda cheating.Unfair bias in the judging, so I'll take out the extra optimization forthe next cut. Unicon can't win by being sneaky, and then getting areputation of fanbois spreading fake news. ;-)  I have some experience in VAX/VMS and RSX-11M too. These things were always such interesting and intruguing for me... But then I left defence and gone to freedom :-) I am now settled at Saint-Petersburg (not Florida, but Russia). As for M$ it's not bad OS now at all, however I could choose any other Linux-like system. For example, I keen on Raspbian for my tiny RP2.Need to get a Pi. I'm doing a side project with a PIC Microchipmicrocontroller at the moment, 18F67J60, 3K of RAM but a goodly pile offlash (128K). No Unicon for that beefy little chip, but oh well. :-)Just got word that GnuCOBOL was successfully compiled on aPocketC.H.I.P. $9 removable single board computer C.H.I.P. R8, with a$60 screen/keyboard/case. Need to pick up some new toys.  But last year I had practically no time to work on it. I had to do more prosaic tasks unfortunately. Having Windows don't limit now the user only by it. On my Win10 Pro I've installed Linux Subsystem (embedded component of Windows itself), so I can fastly switch to Linux shell if needed. Other great option now is Docker. With help of it you can run virtual container with any other system/OS. Direction of last days is that Windows, Linux and Mac can live on the same single hardware as a whole ecosystem. Without any multiboot options.True, still, no Windows from here. I see too many COBOL programmersthat can't build non trivial software because MS has hidden so manydetails and trained them to click click and not really think think;which they are all more than capable of if they gave up on the spoonfeeding for a week or two and learned some of the more basic usageskills. (By build, I don't mean develop, I mean ./configure; make orconfiguring a VS project - even setting the PATH seems like a strugglefor some (and these are very smart people)).Same for some highly skilled mainframe coders; most never get a chanceto operate the machine so it all seems like voodoo. Now they can tryHercules to run MVS, but they can't get much further then the boot upIPL (initial program load) because they have little experience with somefeatures of the OS (that they have used for the last 40 years). Insteadthey seem to need to be told what PF keys to hit and in what order, thenget defensive about not knowing a skill (that they should) and then getall mad that there isn't a magic PF key to hit. :-)  My troubles with loadfunc is that I've never built shared/dynamic library. I tried it on CygWin but failed for some reason. I think that it because I have not too much knowledge of gcc. Does it really a fruit of your hands/brains? I am holding breath! Great, magestic, tremendous, ...Case in point, Sergey. It comes down to just a little bit of trainingand practice that a large corporation has held back from you (onpurpose, as part of a business model). Or, at least, has not overlyadvertised as available. Don't fall for it. Dig in, and dig out fromunder. Explore freely. Use the command line for Windows compilers forinstance. Not all the time, but sometimes. Get used to all thesettings and switches that the GUI is hiding on you. Hard at first,then it's not. You don't really need to memorize all the details, butjust enough to know where to look.  Sincerely, Sergey P.S. By the way, this very simple xmarkup script below can also visualize your data: # Histogram visualization [Options] encoding = ANSI graphics = true [Procedures] p

Re: [Unicon-group] unicon -C ==> -fs tweak

[Sergey Logichev]

   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 slogic...@yandex.ru> slogic...@yandex.ru 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>  jeffe...@uidaho.edu jeffe...@uidaho.edu>>)" <jeffe...@uidaho.edu jeffe...@uidaho.edu>  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 clint.jeff...@gmail.com>  clint.jeff...@gmail.com 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 clint.jeff...@gmail.com>  clint.jeff...@gmail.com 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

Re: [Unicon-group] unicon -C ==> -fs tweak

[Brian Tiffin]

Sergey Logichev wrote:
> So, it's unfortuanately just a misprint: "Unicon -load 0,04 ... C
> 0,05"? One percent slower it is also great!
Not really a misprint as it turns out;  I just updated the doc, but now
I see what I did on third look.  The loadfunc version of the gcc C code
uses -O3, so it does actually time at 0.04, but it's kinda cheating. 
Unfair bias in the judging, so I'll take out the extra optimization for
the next cut.  Unicon can't win by being sneaky, and then getting a
reputation of fanbois spreading fake news.   ;-)

> I have some experience in VAX/VMS and RSX-11M too. These things were
> always such interesting and intruguing for me...
> But then I left defence and gone to freedom :-) I am now settled at
> Saint-Petersburg (not Florida, but Russia).
> As for M$ it's not bad OS now at all, however I could choose any other
> Linux-like system. For example, I keen on Raspbian for my tiny RP2.
Need to get a Pi.  I'm doing a side project with a PIC Microchip
microcontroller at the moment, 18F67J60, 3K of RAM but a goodly pile of
flash (128K).  No Unicon for that beefy little chip, but oh well.  :-)

Just got word that GnuCOBOL was successfully compiled on a
PocketC.H.I.P.  $9 removable single board computer C.H.I.P. R8, with a
$60 screen/keyboard/case.  Need to pick up some new toys.

> But last year I had practically no time to work on it. I had to do
> more prosaic tasks unfortunately.
> Having Windows don't limit now the user only by it. On my Win10 Pro
> I've installed Linux Subsystem (embedded component of Windows itself),
> so I can fastly switch to Linux shell if needed. Other great option
> now is Docker. With help of it you can run virtual container with any
> other system/OS.
> Direction of last days is that Windows, Linux and Mac can live on the
> same single hardware as a whole ecosystem. Without any multiboot options.

True, still, no Windows from here.  I see too many COBOL programmers
that can't build non trivial software because MS has hidden so many
details and trained them to click click and not really think think;
which they are all more than capable of if they gave up on the spoon
feeding for a week or two and learned some of the more basic usage
skills. (By build, I don't mean develop, I mean ./configure; make or
configuring a VS project - even setting the PATH seems like a struggle
for some (and these are very smart people)).

Same for some highly skilled mainframe coders; most never get a chance
to operate the machine so it all seems like voodoo.  Now they can try
Hercules to run MVS, but they can't get much further then the boot up
IPL (initial program load) because they have little experience with some
features of the OS (that they have used for the last 40 years).  Instead
they seem to need to be told what PF keys to hit and in what order, then
get defensive about not knowing a skill (that they should) and then get
all mad that there isn't a magic PF key to hit.  :-)

> My troubles with loadfunc is that I've never built shared/dynamic
> library. I tried it on CygWin but failed for some reason. I think that
> it because
> I have not too much knowledge of gcc. Does it really a fruit of your
> hands/brains? I am holding breath! Great, magestic, tremendous, ...
Case in point, Sergey.  It comes down to just a little bit of training
and practice that a large corporation has held back from you (on
purpose, as part of a business model).  Or, at least, has not overly
advertised as available. Don't fall for it.  Dig in, and dig out from
under.  Explore freely.  Use the command line for Windows compilers for
instance.  Not all the time, but sometimes.  Get used to all the
settings and switches that the GUI is hiding on you.  Hard at first,
then it's not.  You don't really need to memorize all the details, but
just enough to know where to look.

> Sincerely,
> Sergey
>  
> P.S. By the way, this very simple xmarkup script below can also
> visualize your data:
> # Histogram visualization
> [Options]
> encoding = ANSI
> graphics = true
>  
> [Procedures]
> procedure initialize
>   data := []
>   put(data,["Uni",2.02, "green"])
>   put(data,["Un.C",0.55, "green"])
>   put(data,["Un.l",0.04, "green"])
>   put(data,["Py",2.06, "blue"])
>   put(data,["C",0.05, "red"])
>   put(data,["Ada",0.06, "red"])
>   put(data,["ALG",5.91, "red"])
>   put(data,["Asm",0.01, "red"])
>   put(data,["BAS", 0.05, "red"])
>   put(data,["CBL", 0.06, "red"])
>   put(data,["D",0.05, "red"])
>   put(data,["ECMA",0.83, "blue"])
>   put(data,["Elix", 2.03, "blue"])
>   put(data,["Forth",0.52, "blue"])
>   put(data,["For",0.06, "red"])
>   put(data,["Genie",0.16, "red"])
>   put(data,["Java", 0.11, "red"])
>   put(data,["Lua",0.73, "blue"])
>   put(data,["Neko", 0.89, "red"])
>   put(data,["Nim",0.31, "red"])
>   put(data,["Perl",1.29, "blue"])
>   put(data,["PHP",0.39, "blue"])
>   put(data,["Rebol", 2.22, "blue"])
>   put(data,["Rexx", 2.38, "blue"])
>   put(data,["Ruby",1.16, "blue"])
>   put(data,["Sch",0.85

Re: [Unicon-group] unicon -C ==> -fs tweak

[Sergey Logichev]

Brian, So, it's unfortuanately just a misprint: "Unicon -load 0,04 ... C 0,05"? One percent slower it is also great!I have some experience in VAX/VMS and RSX-11M too. These things were always such interesting and intruguing for me...But then I left defence and gone to freedom :-) I am now settled at Saint-Petersburg (not Florida, but Russia).As for M$ it's not bad OS now at all, however I could choose any other Linux-like system. For example, I keen on Raspbian for my tiny RP2.But last year I had practically no time to work on it. I had to do more prosaic tasks unfortunately.Having Windows don't limit now the user only by it. On my Win10 Pro I've installed Linux Subsystem (embedded component of Windows itself),so I can fastly switch to Linux shell if needed. Other great option now is Docker. With help of it you can run virtual container with any other system/OS.Direction of last days is that Windows, Linux and Mac can live on the same single hardware as a whole ecosystem. Without any multiboot options.My troubles with loadfunc is that I've never built shared/dynamic library. I tried it on CygWin but failed for some reason. I think that it becauseI have not too much knowledge of gcc. Does it really a fruit of your hands/brains? I am holding breath! Great, magestic, tremendous, ...Sincerely,Sergey P.S. By the way, attached very simple xmarkup script can also visualize your data. I had to cut a message to get it less than limit of 40 kB :-(( 13.06.2017, 13:06, "Brian Tiffin" :Sergey Logichev wrote: Brian, Performance gain >4x sounds quite pretty. I see that using loadfunc gives about the same speed as pure C (and even faster!!!).Oops. Cognitive bias typo. ;-) I'll fix that. loadfunc is NOT fasterthan plain C, but on par for this test, perhaps a percentage or threeslower. Thanks for prompting me take a second closer look at that chartand the graphic. 

hist-performance.par
Description: Binary data
--
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

Re: [Unicon-group] unicon -C ==> -fs tweak

[Brian Tiffin]

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
>> <mailto:jeffe...@uidaho.edu>
>>  <mailto:jeffe...@uidaho.edu
>> <mailto:jeffe...@uidaho.edu>>)" > <mailto:jeffe...@uidaho.edu>
>>  <mailto:jeffe...@uidaho.edu <mailto: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
>> <mailto:clint.jeff...@gmail.com>
>>  <mailto:clint.jeff...@gmail.com
>> <mailto: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"
>> mailto:clint.jeff...@gmail.com>
>>  <mailto:clint.jeff...@gmail.com
>> <mailto: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 / mixin

Re: [Unicon-group] unicon -C ==> -fs tweak

[Sergey Logichev]

its 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 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>)" <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 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 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 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:  Par

Re: [Unicon-group] unicon -C ==> -fs tweak

[Brian Tiffin]

d 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
>> <mailto:jeffe...@uidaho.edu>)" > <mailto: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
>>> <mailto: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" >> <mailto: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
>>>> mailto: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:
>>>> ..
>>>> Par

Re: [Unicon-group] unicon -C ==> -fs tweak

[Sergey Logichev]

Jafar, That are the great news! I hope the implementation of iconc approach to build will be completed soon. I am very interesting in that as I suppose performance will increase on some factor. I am waiting with patience.Good luck!Sergey 13.06.2017, 09:27, "Jafar Al-Gharaibeh" :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  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)" :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 LogichevDate: Tue, Jun 13, 2017 12:55 AMTo: 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" :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  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: ...

Re: [Unicon-group] unicon -C ==> -fs tweak

[Jafar Al-Gharaibeh]

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 
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" :
>
> 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 
> 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: ..
> .

Re: [Unicon-group] unicon -C ==> -fs tweak

[Sergey Logichev]

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)" :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 LogichevDate: Tue, Jun 13, 2017 12:55 AMTo: 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" :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  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 approac

Re: [Unicon-group] unicon -C ==> -fs tweak

[Jeffery, Clint (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" :
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 
mailto: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" 
mailto: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 numb

Re: [Unicon-group] unicon -C ==> -fs tweak

[Jafar Al-Gharaibeh]

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 
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" :
>
> 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 
> 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" :
>
> 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
>
> ,
>
> --

Re: [Unicon-group] unicon -C ==> -fs tweak

[Sergey Logichev]

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" :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  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" :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 mostengaging tech sites, Slashdot.org! http://sdm.link/slashdot,___Unicon-group mailing listUnicon-group@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/unicon-group--
Check ou

Re: [Unicon-group] unicon -C ==> -fs tweak

[Clinton Jeffery]

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 
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" :
>
> 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.n

Re: [Unicon-group] unicon -C ==> -fs tweak

[Sergey Logichev]

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" :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 mostengaging tech sites, Slashdot.org! http://sdm.link/slashdot,___Unicon-group mailing listUnicon-group@lists.sourceforge.nethttps://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

Re: [Unicon-group] unicon -C ==> -fs tweak

[Steve Wampler]

On 06/12/2017 11:17 AM, Jeffery, Clint (jeffe...@uidaho.edu) wrote:

Steve,


I (just now in response to your request) added a -nofs option to disable the 
default -fs if -C is used, as in


unicon -C -nofs hello


to allow you to observe just how big the code blow-up  of -fs is.  Perhaps I 
need a better name than -nofs.


I'm happy with -nofs.  Thanks!

--
Steve Wampler -- swamp...@noao.edu
The gods that smiled on your birth are now laughing out loud.

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

Re: [Unicon-group] unicon -C ==> -fs tweak

[Jeffery, Clint (jeffe...@uidaho.edu)]

Steve,


I (just now in response to your request) added a -nofs option to disable the 
default -fs if -C is used, as in


unicon -C -nofs hello


to allow you to observe just how big the code blow-up  of -fs is.  Perhaps I 
need a better name than -nofs.

What do you think, -FS  ?   --fs  ?


From: Steve Wampler 
Sent: Monday, June 12, 2017 10:49:46 AM
To: unicon-group@lists.sourceforge.net
Subject: Re: [Unicon-group] unicon -C ==> -fs tweak

Hi Clint,

On 06/12/2017 10:46 AM, Clinton Jeffery wrote:
> 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.

Is there a command line option to turn it off if we want to experiment?

Thanks,
Steve


--
Steve Wampler -- swamp...@noao.edu
The gods that smiled on your birth are now laughing out loud.

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

Re: [Unicon-group] unicon -C ==> -fs tweak

[Steve Wampler]

Hi Clint,

On 06/12/2017 10:46 AM, Clinton Jeffery wrote:
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.


Is there a command line option to turn it off if we want to experiment?

Thanks,
Steve


--
Steve Wampler -- swamp...@noao.edu
The gods that smiled on your birth are now laughing out loud.

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