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, "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
Cool. I'll give it a try. charting.icn is using the IPL barchart
function, which rescales the entire graph as new maximum and minimums
are detected, which is nice, but the colour selectors go out of whack
during second (or more) redraws. I stuck with blue for the whole thing.
Initial intention was to separate out compiled/interpreted and Unicon.
If colours can be made to work, and with hind site compiled to VM
languages would get a colour too (Unicon still separate, just because,
it's a Unicon book).
Thanks, Sergey, xmarkup looks worth checking out. Scanning through the
win32/src/console dir at the moment.
Cheers,
Brian
------------------------------------------------------------------------------ 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
