Brian,
 
Performance gain >4x sounds quite pretty. I see that using loadfunc gives about the same speed as pure C (and even faster!!!).
Your investigations are damned interesting as usual. I will be glad to help you in some degree. If you need programmers to write
sample average Unicon code for expertize. I am not an programmer expert at all, however make the game with Icon ~20 years.
I am very well remember the day when I at first time read about Icon at PC Magazine at the beginning of 90th. I was employed at that times for
Soviet defence and had access to US/English magazines in the library. The language was such beautiful after algol, Fortran, PL/I and C, that
I got the bravery and wrote to Ralph Griswould himself. So after while he answered (!!!) and sent me back free of charge
diskette with MS-DOS Icon version 8. It was not easy to start without documentation and any book, but some years later we
started to communuicate with our antogonistic colleagues from US (at the times of Gorbachev's perestoika) and they granted me the book
"Icon Programming Language". After that Icon is my prefered choice!
 
As first step I would propose my own program https://sourceforge.net/projects/xmarkup. It may be treated as general usage framework,
which may be used for very wide range of tasks: from text analysis to numeric calculations and data visualizations.
 
My best wishes,
Sergey
 
P.S. Could you help me in mastering loadfunc() functionality on Windows? I still didn't manage to do that. The main obstacle is how to build a library.
 
13.06.2017, 11:21, "Brian Tiffin" <bwtif...@gmail.com>:

Sergey Logichev wrote:

 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


Excuse the topic drift everyone:

Sergey, for a hint on one small aspect of performance gain, expect about
4 times raw speed for simple numeric operations. Due to the large
integer semantics in Unicon, that are managed implicitly with the small
program sample used, that number may be low overall. You can expect more
gain from some operations, and less from others. It will be interesting
to see how a mix averages out. Hypothesis at this point is that 4x is
the low end of the scale.

See http://btiffin.users.sourceforge.net/up/performance.html#summary

I'll expand on that article to cover more than just summing integers
soon. The entire chapter is meant to be a double edged sword, though.
Development time with Unicon is the star of the show really, but that is
a fairly hard metric to articulate without real world numbers to back it up.

The summing integers example is too short, and differences in
development times are negligible. The next few entries in that chapter
will try and document more complex problems, and track how long it takes
to get correct and reliable solutions. That will likely be a hard thing
to do objectively. Especially as an individual (with very pro Unicon
bias and various (low) levels of expertise with most development
environments). I'll try and and find some volunteers that have their
own favourites to tackle a set of problems and record the efforts. That
will take a while to organize. The goal is to exclude guru level
programmers, as those masters are the exception and not generally the
rule when measuring the productivity of most software developers.

One issue that may make that even more difficult (and I don't think this
a provable point without a large scale study), is that Unicon developers
may already be a little bit outside the normal curve. I personally
think that the average "average programmer" may feel a little bit
daunted when faced with some of the features inherent in Unicon, and
might not become Unicon programmers. Those that do, by choice, have
already shown a particular bias and set of attributes. Like Forth;
those that get it, fly; those that don't, walk away and do something
else. Same with functional ala Haskel, or Lisp like or .... There is
an almost audible clicking noise when people first encounter a language
that they are going to "get" and have an innate knack for. :-) Very
much like trying to predict someone's favourite colours or types of
music. It's almost impossible without asking (and with music, can be
outright surprising sometimes).

Have good, make well,
Brian
 

 
 13.06.2017, 09:27, "Jafar Al-Gharaibeh" <to.ja...@gmail.com>:
 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 <mailto: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
     <mailto:jeffe...@uidaho.edu>)" <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" <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 / 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 <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"
         <clint.jeff...@gmail.com <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 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 <http://sdm.link/slashdot>

         ,

         _______________________________________________
         Unicon-group mailing list
         Unicon-group@lists.sourceforge.net
         <mailto: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
     <mailto: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

Reply via email to