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 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, ...
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, "blue"])
put(data,["SLang",4.92, "blue"])
put(data,["Snobl",5.83, "blue"])
put(data,["JTcl",4.59, "blue"])
put(data,["Tcl",17.69, "red"])
put(data,["Vala",0.16, "red"])
w := WOpen("size=1200,800")
Hist(data,"Performance: comparing Unicon with other languages","blue")
read(w)
end
13.06.2017, 13:06, "Brian Tiffin" <bwtif...@gmail.com>:
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,
Brian13.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
