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 faster than plain C, but on par for this test, perhaps a percentage or three slower. Thanks for prompting me take a second closer look at that chart and the graphic.
> 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! Cool story, thanks. My first go at Icon was V6 on VAX/VMS shortly after getting GCC compiled. Ralph was and will always be one of my heroes. Clinton's name made the rounds when we later compiled Icon for DECWindows. Most of my colleagues had to be convinced that complex graphics programming was that easy. :-) > > 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. Sounds like a worthy path to explore once the task bubbles up to the top of the to-do pile. > > 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. Perhaps. I rarely touch Windows anymore. (On to the soapbox). The last machine I bought, right at the time when there was no signed keys for Linux, I disabled UEFI boot and low level formatted the hard drive for the favoured OS. I used to dual boot, but the gutless FUD move of UEFI just meant they lost a programmer, who will never care to touch Windows again. I now actively tell other programmers that I think they are being unfairly treated when using Windows, both in terms of general computing education and regarding the right to exercise personal freedoms. (They actually lost me back when trying to kill off OS/2, but I at least tried to help people with Cygwin issues. Not anymore.) Something like 6? years now, clean and clear, no regrets. Gutless move by MS playing into the fears of people that don't know, or don't care to know better. Shame on them for trying to slow down progress yet again for greed and with malice. Non-technical people have an excuse to use a consumer grade OS, but I'd like to think that programmers deserve more and should actively seek alternatives at the expense of just a little effort. (End soapbox). If you have particular questions, I might still remember some tricks to make things work, Sergey. Have good, Brian > > 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 >> <mailto: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> >> <mailto: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> >> <mailto:jeffe...@uidaho.edu >> <mailto:jeffe...@uidaho.edu>>)" <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" >> <clint.jeff...@gmail.com <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 / 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> >> <mailto: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> >> <mailto: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> >> <mailto: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> >> <mailto: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
