Re: [Unicon-group] Unicon and native C
On Sat, Dec 31, 2016 at 06:52 AM, Don Ward wrote: On 30 Dec 2016, at 03:34, btif...@vivaldi.net (mailto:btif...@vivaldi.net) wrote: Jafar, Clinton; I need a little education on the new mkExternal feature in icall.h, as I could not get a working sample. Currently, pointer data is just sent back as an integer handle (which will break on some platforms), and I'd like to extend the supported types to C structs and pointers to memory blocks, etc. I hope that just a short working example on what the actual C data type declaration is to start running with it; could not tell from the macro, so I thought I'd just ask instead of flailing about. I’m guessing we’re talking about revision 4642 here. If so, the “guilty party” is me. The intention is that an external value is an opaque type: something that is generated by the C code, passed into the Unicon code and given back as required. The Unicon code should not manipulate it or poke around inside it —it’s supposed to be opaque — just give it back to the C code when needed. A good example of it’s use (which will be coming to a distribution near you fairly soon, I hope) is the way that RFC6234 handles the secure hash context. The context, which is created by the routines, is passed back to the caller, which gives it back to the hash routine for each subsequent operation. I hope that makes things a bit clearer. Sorry for the confusion, but the RF6234 code, which would have provided an example of how to use mkExternal, is still in the works, awaiting some changes to how things are organised. Regards Don Thanks, Don. I'm starting to get my head around it a little more. It will come in handy on the next update of uniffi, as I'll be adding struct data passing and return types. It took a little while to unsquirrel the list management, and I'll be asking for feedback on how that might be improved on, and strengthened. I had to add the b_elem struct to my local copy of icall.h to make it easier on the brain, but then stumbled into how IListVal and RListVal works, and went from there. It is simpler now, then when I was flailing, but I'm not overly sure it's safer or the most efficient. libffi and calling C routines without loadfunc is pretty handy (and much fun). The libffi cut has a lot of platforms covered, including s390 z/Linux, and Windows and Mac, and FreeBSD and on and on. Making for some pretty neat experiments. Listings are up at, http://btiffin.users.sourceforge.net/up/multilanguage.html#libffi (http://btiffin.users.sourceforge.net/up/multilanguage.html#libffi) Still work to do, a lot more tests, adding in all the data subtypes, etc. But it already covers a lot of bases. And not that much code. Worked out the double/float typing problem by using a two element list for arguments that need to be demoted. There is more subtyping to do, and figure out some way of allowing mutable call by content without risking Unicon core types. It'll almost assuredly come down to make temporary or tended copies, and adding another function for accessing the result sets (might be lists, records, encoded strings, whatever structure it ends up looking like for the Unicon programmer side). Have good, happy 2017 everyone, 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
[Unicon-group] Unicon and native C
I've been experimenting with ways to call C and COBOL functions without need
for a wrapper.
Tests are working out well with (a very platform specific) inline assembly
layer.
The test COBOL
identification division.
program-id. sample.
data division.
linkage section.
01 one usage binary-long.
01 two usage binary-long.
procedure division using by value one two.
sample-main.
display "GnuCOBOL got " one ", " two
compute return-code = one + two
goback.
end program sample.
And the test Unicon
#
# testcob.icn, test calling COBOL without wrapper
#
$include "natives.inc"
procedure main()
# will be RTLD_LAZY | RTLD_GLOBAL (so add to the search path)
addLibrary := loadfunc("./uninative.so", "addLibrary")
# allow arbitrary C functions, marshalled by a small piece of assembler
native := loadfunc("./uninative.so", "native")
# add the testing functions to the dlsym search path,
# the handle is somewhat irrelevant, but won't be soonish
dlHandle := addLibrary("./cobolnative.so")
# initialize GnuCOBOL
native("cob_init", TYPEVOID)
# pass two integers, get back a sum
ans := native("sample", TYPEINT, 40, 2)
write("Unicon: called sample and got ", ans)
# rundown the libcob runtime
native("cob_tidy", TYPEVOID)
end
Result pass
prompt$ cobc -m cobolnative.cob
prompt$ unicon -s testcob.icn -x
GnuCOBOL got +40, +02
Unicon: called sample and got 42
Sad part, the inline assembly is only x86_64 System V ABI at the moment.
(about 70 lines of inline extended assembler code, some 17 instructions, to
manage both integral and double sized reals, input (freely mixed types) and
return). That code needs to change to handle floats (versus double) another 17
instructions, without any refactoring. At this point in time, a single
function can't have mixed C float and double data, all other type mixes are
testing well, but this is only a few hours in to the experiments. Somewhat
cherry picked testing, but integer, pointer/handle, real, and string data is
functional. There will be edge cases to find and work out, and details
regarding memory ownership and the like. This builds on the existing loadfunc
feature but most details are then managed by a single entry point,
"native(...)".
Windows 64 and 32 and other operating environments should be in the same range
of instruction counts, but I'll know a little more once 32bit GNU/Linux is
tackled, with the different call frame rules. It might be upwards of 30
instructions that need to be hand coded, not an overly burdensome burden for
the powers that it provides to Unicon, in my biased opinion. No wrappers
required to get at C library functions.
Jafar, Clinton; I need a little education on the new mkExternal feature in
icall.h, as I could not get a working sample. Currently, pointer data is just
sent back as an integer handle (which will break on some platforms), and I'd
like to extend the supported types to C structs and pointers to memory blocks,
etc. I hope that just a short working example on what the actual C data type
declaration is to start running with it; could not tell from the macro, so I
thought I'd just ask instead of flailing about.
More at
https://sourceforge.net/p/unicon/discussion/contributions/thread/4f3103fc/
(https://sourceforge.net/p/unicon/discussion/contributions/thread/4f3103fc/)
And an initial usage sample that embeds libharu for PDF generation at
https://sourceforge.net/p/unicon/discussion/general/thread/5e5d4ab1/
(https://sourceforge.net/p/unicon/discussion/general/thread/5e5d4ab1/)
If this seems like a want-able thing by the Unicon community, it'll require a
small piece of assembler for each platform that wants to take part. Getting
cross-platform, by writing to each platform. ;-) If that happens, there will
be a call out for volunteers that have access to various C compiler versions
and OS releases on various chipsets. Expect less than a page of code per
platform.
Have good, make well, happiest of 2017s,
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
[Unicon-group] Unicon .o object file output and linking from C/COBOL
I just posted another question. An example of a Unicon program compiled by unicon -C converted to allow gcc to create a .o file that is linked into a COBOL program. COBOL calling Unicon and getting at some data on the way out. Works well, but currently fragile. I'd like opinions and advice on how/if unicon -C can be slightly tweaked to allow Unicon to generate code that other compilers and programming environments can use without fuss. (how/if, as in, if it should). https://sourceforge.net/p/unicon/discussion/contributions/thread/d15b4085/ (https://sourceforge.net/p/unicon/discussion/contributions/thread/d15b4085/) I get a sense that most people on the list don't bother visiting the SourceForge project space yet, but I'd really appreciate some feedback on this one. It could be big, (or it could fizzle and spin around on the floor to become dust), but I'm aiming for big. Unicon generating object files that can be used in C, C++, Fortran, COBOL, Vala, Python, Perl, any language that can link to C ABI object code. Two small changes to the output from unicon -C and some assumptions in a Makefile. 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
Re: [Unicon-group] The vagaries of creating a new copy of the Unicon Book from TeX sources.
On Fri, Dec 9, 2016 at 08:50 AM, Bruce & Breeanna Rennie wrote: Good evening/morning to all, For those who may be attempting to create a new pdf from the Unicon TeX sources, I have the following story. If, like me, you are running on a Centos 6 system, the make file provided will probably fail (if you are using tex-live as supplied). There are missing macros which do not seem to be available in the distro version of tex-live. For building the UP docs and other Sphinx TeX output related materials, I usually install texlive-full, it's a few gigabytes of install, and most components sit idle, never used, but it saves on thinking through the thousands of sub packages. After that, things all come together, dependencies met. On this Xubuntu 16.04 box, and the Fedora 24 system, the makefile for ub.pdf just works. Can't say which package(s) from the complete Tex suite make it work, but it does. I suggest to those who experience this that you download the tex-live 2016 DVD iso and do a clean install using that. I did have problems trying to do a net install of tex-live 2016 (failed 1/2 way through with a hard non-resumable error). Do your install of the new tex-live and after completing any path changes required, log-out, log-in and run make and you will have the new version. To the Authors, looks good with the changes that I have seen so far. Thank you for your efforts in this work. Agree. Kudos deserved. Cheers, Brian regards Bruce Rennie -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today.http://sdm.link/xeonphi (http://sdm.link/xeonphi) ___ Unicon-group mailing list Unicon-group@lists.sourceforge.net (mailto:Unicon-group@lists.sourceforge.net) https://lists.sourceforge.net/lists/listinfo/unicon-group (https://lists.sourceforge.net/lists/listinfo/unicon-group) -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today.http://sdm.link/xeonphi___ Unicon-group mailing list Unicon-group@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/unicon-group
[Unicon-group] Another path to JSON and some other niceties
I've been adding loadfunc samples for a bunch of Symisc source releases. PH7, vedis, UnQLite. The UnQLite layer adds Jx9 scripting as the JSON document store part, along with the impressively performant key-value store. http://btiffin.users.sourceforge.net/up/programs.html#unqlite (http://btiffin.users.sourceforge.net/up/programs.html#unqlite) PH7 for an embedded PHP engine, vedis for an embedded Redis clone (with some pretty neat storage and retrieval commands). I'm going to take a kick at the libcox bundle as well, it allows for cross-platform evaluation for a bunch of POSIX related commands, set to work with Windows as well as the nixlike operating environments. https://unqlite.org/support.html (https://unqlite.org/support.html) for quick links to the bundles. Symisc follows the SQLite model of amalgamation source bundles. All you need to do is add a .c file in your build and everything gets included. Handy (and like Dr. Hipp found with SQLite, amalgams allows for very efficient C compiler optimizations as there is nothing split across source units). 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
[Unicon-group] Pygments highlighter, alpha release
Hello, all I've just posted up an early trial copy of the Unicon lexer for source highlighting. After these many months, I'll be on BitBucket shortly and put in a pull request to have the file added to the Pygments main. Some time after that, it'll show all unicon tagged source listings on SourceForge with colour. (And Wikipedia, and the like, any site that uses Pygments, and there are a lot). https://sourceforge.net/p/unicon/discussion/contributions/thread/824619c3/ (https://sourceforge.net/p/unicon/discussion/contributions/thread/824619c3/) Cheers, Brian -- ___ Unicon-group mailing list Unicon-group@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/unicon-group
Re: [Unicon-group] Converting strings to patterns
On Tue, Nov 29, 2016 at 08:45 PM, Don Ward wrote: I should have been a bit
clearer when I said my program didn’t work. It does, but only for fixed
strings: there is none of the RE special character magic. And, I agree, the
crucial question is how to construct a pattern from a string that treats the
special characters as special characters, rather than just literals.
In passing, write( type( )) writes string, whereas write(type( )) writes
pattern, which isn’t quite what I expected.
I had quite high hopes for Arbno(), but soon realised that it wanted a pattern
for its argument, not a string and, even when I fed it with a variable that had
the type of pattern, it still didn’t work how I might have expected it to. At
that stage, I asked my original question. If Clint’s “option #1" is "write a
library procedure that parses the regex and builds the corresponding pattern”,
I wonder whether Arbno() might be a suitable interface: i.e. if it’s a pattern
already, do what it does now, otherwise turn the string into a pattern and then
do it. Perhaps a separate procedure might be clearer.
The reader with no time for trivia may profitably skip the rest of this message
...
I may have found a use for Succeed: If I modify my program to be as below
(additions in red: the reason for the strange comment at the end will be clear
in a moment)
procedure main(args)
local f, line, re := pop(args) || Succeed()
write(type(re))
every f := open(!args, "r") do {
every line := !f do {
if ( line ?? re ) then write(line)
}
}
end
#[dne][edn][den]
If I use grep on this program source I get
bash-3.2$ grep "[dne][edn][den]" gerp.icn
local f, line, re := pop(args) || Succeed()
end
#[dne][edn][den]as expected: grep has found “eed", “end" and the regular
expression itself in the final comment. Whereas, if I use the program on its
own source code I get
bash-3.2$ ./gerp "[dne][edn][den]" gerp.icn
pattern
#[dne][edn][den]showing that although I have a pattern, it isn’t interpreting
the special characters.
Don, this isn't run time regex. Regex literals are preprocessed before the
compile.
Look at unicon -E gerp.icn
to see how it is the preprocessor phase that expands the special meanings, by
generating Unicon function expressions.
The program patstr.icn
procedure main(argv)
local f, line, re := pop(argv)
a :=
write(type(a))
b :=
write(type(b), " ", string(b))
p := pattern_concat("", re)
write(type(p))
every f := open(!argv, "r") do {
every line := !f do {
if line ?? p then write(line)
}
}
end
Expands to
prompt$ unicon -E patstr.icn
Parsing patstr.icn: .
/home/btiffin/unicon/bin/icont -c -E -O patstr.icn /tmp/uni13423387
patstr.icn:
#line 0 "/tmp/uni13423387"
#line 0 "patstr.icn"
procedure main(argv);
local f, line, re;
#line 13 "patstr.icn"
re := pop(argv)
a := pattern_concat("abc", (Arbno('abc')));
write(type(a));
b := pattern_concat("abc", Any('abc'));
write(type(b), " ", string(b));
p := pattern_concat("", re);
write(type(p));
every f := open(!argv, "r") do {
every line := !f do {
if( "" ? pattern_match( line,p)) then write(line)
}
};
end
No errors
The Unicon VM nevers see the literals, it see the results of pattern_xxx
constructors and functions. Along with use of Arbno() to handle the Kleene
stars and character set square brackets.
unicon -E will show more clearly what is going on, and the separation of
compile time and runtime behaviour, and what is going to be allowed with regex
literals.
Cheers,
Brian
If I miss off the "|| Succeed()” from the initialisation of re and try again I
get
string
#[dne][edn][den]
I still get a pattern match, even though it’s a string not a pattern, but it’s
the literal string that is matching.
Therefore Succeed() may be used to turn a string into a pattern! Unfortunately
not in a useful way.
On 29 Nov 2016, at 22:27, Jeffery, Clint (jeffe...@uidaho.edu
(mailto:jeffe...@uidaho.edu)) wrote:
My thanks to Don, Jay, and anyone else who is trying out stuff related to
patterns. I am on the road ATM but will work on improving the diagnostics
related to Jay's experiments. Regarding Don's original request and Jay's
comments on it: backquotes in patterns is not a full "eval" interpreter that
will take arbitrary Icon strings and turn them into code. Maybe we need that,
and maybe someone will build it some day. In the meantime, after figuring out
the best workarounds that may be available, you can judge for yourself whether
the patterns are still useful, or whether they remain unfinished business.
Th
[Unicon-group] Demos index page
To entice some involvement, hint, hint, wink, wink, I've put up a semi reasonable looking index page for Unicon networking demos at http://btiffin.users.sourceforge.net/demos/ (http://btiffin.users.sourceforge.net/demos/) Two simple forms so far; the aforementioned CGI form, and a new AJAX front end. Both use the same server side Unicon executable (link cgi), but the AJAX form jumps a few years and puts Unicon boasting firmly in the early third millennium and not looking like a mid 1990s web utility. (Although, these pages still "look" like 1995, the AJAX sample shows off technology from a decade later). :-) There is a request for more contributions at https://sourceforge.net/p/unicon/discussion/contributions/thread/ac9be1b0/#7119 (https://sourceforge.net/p/unicon/discussion/contributions/thread/ac9be1b0/#7119) If you have something, anything really, that boasts Unicon networking, drop a note on that thread, or respond here to start the wheels in motion for getting the Unicon sources compiled on the SourceForge servers and putting a link into the index page mentioned at the top of this note. These first two have pretty much proven themselves now, and the next cut will include some CSS to make the phase 2 CGI pages look more 2005ish, (unless someone else wants to step up and design some outputs that put Unicon in a 2020 light). Hint hint wink wink. Have good, make demos, Brian -- ___ Unicon-group mailing list Unicon-group@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/unicon-group
[Unicon-group] New Unicon Programming docset alternate location
Hello, everyone, I've put a copy of the UP docs on SourceForge at http://btiffin.users.sourceforge.net/up/ (http://btiffin.users.sourceforge.net/up/) This is an alternate while I figure out some choices on hosting services, and will likely change again soon. And by the by, Unicon latest is running on the forge now. A small sample at http://btiffin.users.sourceforge.net/form.html (http://btiffin.users.sourceforge.net/form.html) kicks a Unicon CGI application (well, a simple demo really) as a proof of concept. The SourceForge developer web runs a version of CentOS 6.8 (at the moment). Pulling sources for Unicon revision 4616, configure and build went very smoothly. This should be the start of being able to host and boast Unicon programming right along side the project space. We need to make sure we stay within bounds of the terms of service (not hogging CPU or triggering the Apache servers to access third party services, for instance) but the forge is a very flexible platform. The intent is to show off free software projects, so they allow a wide gamut of features, with very generous terms. Have good, make well, Brian -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi___ Unicon-group mailing list Unicon-group@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/unicon-group
[Unicon-group] Vim syntax highlighting file
In case you aren't visiting the SourceForge discussion pages, I just posted a Vim syntax highlighter for Unicon that could use some testing and feedback. https://sourceforge.net/p/unicon/discussion/contributions/thread/27a00aa9/ Along with that, there was an earlier note about how to update Vim RestructuredText highlighting to smartly highlight Unicon (and Icon) within rst code blocks. https://sourceforge.net/p/unicon/discussion/contributions/thread/7df36e5d/ I'd appreciate any feedback. And although it is later than I first promised, the Pygments lexer is testing well now, with less and less tweaking required as more and more Unicon gets poured through it. I just have to duff it over for public release before putting in a pull request to the Team Pocoo Pygments system. Sometime after that, all the Unicon source code on SourceForge will magically turn to colour. Colour listing are so much nicer on the eyes. And a little more poking. The UP docs are coming along, into the Graphics functions at this point. Almost at the stage where I can start in on writing the book that wants to be written, not the parts that need to be written. Many thanks to Clint, I plagiarized a fair chunk of the Programming with Unicon material when I started getting bored with some of the reference background. (Not bored, wrong word, anxious to get to the new works parts of the plan). I'll update those copied bits once the first round is finally done and put a slightly different spin on the reference material instead of just regurgitating existing information. If at all possible, all the reference points come with a code listing sample. Only code that would not make sense in an auto generated PDF won't have samples that are tested on each and every build of the docset. After that, the plan is to ship the book as a Fossil repository, so anyone that feels like it can make notes and generate their own PDF or HTML with relative ease, and then share those changes (or not) as they please. If the TH1 hooks (built into Fossil) work the way they should, and you allow the permissions, the book can be regenerated by clicking a button on the HTML version. So read a book, edit a book and make a new book from the browser and a local Fossil server; once all the Sphinx doc tools are in place, which is an easy pip install, along with TexLive for the PDF via LaTeX outputs, and a recent Unicon build to run all the examples. http://peoplecards.ca/unicon/index.html Have good, make well, 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
Re: [Unicon-group] A possible (expensive) user defined eval() procedure
On 2016-09-11 14:04, Jay Hammond wrote:
> On 11/09/2016 08:26, btiffin wrote:
>> I'd appreciate any and all feedback on a potential procedure to
>> provide
>> an eval() powers in Unicon.
>>
>> Current first cut trial is using Task load() and on the fly
>> compilation.
>>
>> Reflective properties will allow for pushing and pulling variables,
>> results of last expression can be returned (suspended?) and passed
>> through to the Task co-expression activation.
>>
>> I'm still too new to know if this is a sane plan. Details at
>> https://sourceforge.net/p/unicon/discussion/contributions/thread/6e3bef75/
>>
>> Any and all opinions appreciated.
>>
>> Have good, make well,
>> Brian
>>
>> --
>> ___
>> Unicon-group mailing list
>> Unicon-group@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/unicon-group
>
> Was the code below, the sort of thing you were thinking of? I don't
> understand it, so I may be misleading.
> If it is useful, please feel free to post this thought to the group.
> The file is called ie.icn, and it was a unicon source file (in the
> distribution I guess) and my copy is dated 2015
>
> best wishes, Jay
>
>
>
ie.icn code listing snipped...
Thanks, Jay,
Nope (and Yep). I use ie all the time; as a matter of fact, it got a
little facelift with my local copy to allow command line recall with GNU
readline. See
http://peoplecards.ca/unicon/programs.html#ie-modified-for-readline for
some details. Very similar end-game though. ie runs code as a separate
executable, the plan for uval is to load code into the multi-tasker.
I'm planning on code like this:
#
# uval.icn, an eval function
#
# Author: Brian Tiffin
# Dedicated to the public domain
#
# Date: September 2016
# Modified: 2016-09-11/07:28-0400
#
$define base "/tmp/child-xyzzy"
link ximage
#
# try an evaluation
#
global cache
procedure main()
cache := table()
program := "# temporary file for eval\n_
global var\n_
procedure main()\n_
var := 5\n_
suspend ![1,2,3] do var +:= 5\n_
end"
while e := eval(program) do {
v := variable("var", cache[program])
write("child var: ", v, " e: ", ximage(e))
}
# ISSUE HERE, can't refresh the task space: ^cache[program]
# test cache
v := &null
e := eval(program)
v := variable("var", cache[program])
write("child var: ", v)
write("e: ", ximage(e))
end
#
# eval, given string (either code or filename with isfile)
#
procedure eval(s, isfile)
local f, code, status, child, result
if \isfile then {
f := open(s, "r") | fail
code ||:= every(!read(f))
} else code := s
# if cached, just refresh the co-expression
# otherwise, compile and load the code
if member(cache, code) then write("^cache[code]")
else {
codefile := open(base || ".icn", "w") | fail
write(codefile, code)
close(codefile)
status := system("unicon -s -o " || base || " " ||
base || ".icn 2>/dev/null")
if \status then
cache[code] := load(base)
}
# if there is code, activate the co-expression
if \cache[code] then result := @cache[code]
remove(base || ".icn")
remove(base)
return \result | fail
end
That version is pretty close, but it seems refreshing a Task (to avoid
recompiling code over and over again, once in a cache) fails with an
Attempt to refresh main
For now, it means no working cache, and stays a little more expensive.
eval() might return the co-expression, but it seems more useful if it
produces the value returned from the code itself. And the cache index
might be better as a hash or some such, instead of the raw code string.
See http://peoplecards.ca/unicon/programs.html#eval for ongoing
experiments.
Access to (global) variables is working, any type of result works (all
due to the power of co-expressions, and the multi-tasker) suspension
works (need to figure out when a code reset should occur), but there
needs to be a way of resetting the co-expression, or unloading the Task,
for this to be something practical and not a resource gobbler.
For one-off expressions, or one pass generators, it works well already.
And feels like a built in eval(). The boilerplate "procedure main" etc,
will be factored out for the next trial, and the string won't need to
include that. For filenames passed t
[Unicon-group] A possible (expensive) user defined eval() procedure
I'd appreciate any and all feedback on a potential procedure to provide an eval() powers in Unicon. Current first cut trial is using Task load() and on the fly compilation. Reflective properties will allow for pushing and pulling variables, results of last expression can be returned (suspended?) and passed through to the Task co-expression activation. I'm still too new to know if this is a sane plan. Details at https://sourceforge.net/p/unicon/discussion/contributions/thread/6e3bef75/ Any and all opinions appreciated. Have good, make well, Brian -- ___ Unicon-group mailing list Unicon-group@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/unicon-group
Re: [Unicon-group] Discussion group on SourceForge and miscellaneous ramblings
On 2016-08-18 17:19, Jafar Al-Gharaibeh wrote: > On Wed, Aug 17, 2016 at 10:46 PM, btiffin wrote: > >> http://peoplecards.ca/unicon > > Brian, > > I have been following your updates on the unicon link above, a > really nice job you got there. The organization and the syntax > coloring are great! looking forward to see more material added. > > Cheers, > Jafar Having way too much fun Jafar. :-) I'll apologize to everyone for this early work being a little scatterbrained. There will be good releases and bad releases and fairly random complete breakages while I build up the outline. There are many thousands of features to explore and inconsistencies will rule these early days. As a for instance - like all the examples, the performance page is generated during document build, I may comment some of those entries out for many of the passes as it slows down the doc gen, and I might forget to uncomment that section before an upload, or I might change the code to be less reflective of actual performance just to stub in some numbers. Have good, make well, Brian -- ___ Unicon-group mailing list Unicon-group@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/unicon-group
Re: [Unicon-group] Discussion group on SourceForge and miscellaneous ramblings
On 2016-08-18 07:22, Sergey Logichev wrote:
> Hello Brian,
>
> It sounds very hopefuly to have discussion forum with highliting
> feature for Unicon sources. Suppose, the search also will be available
> (Sphinx?). Hope you will find the understanding with all concerned
> people and teams.
>
> As for https access "bug" - it's unfortunately not supported currently
> by Unicon. I think Clint will tell you about it more detailed. But you
> can use workaround to get https (or ftp or any other) access from
> Unicon. Just use curl utility from https://curl.haxx.se/
> For example,
>
> datafile := "c:\\tmp\\q.q"
> url := "https://some-url/q.q";
> rc := system("curl --output "||datafile||" "||url)
> if /rc then stop("can't run curl")
> w := open(datafile,"r")
> ...
>
> Of course you should add bin path of curl to PATH environment variable
> to run it from Unicon.
>
> Best regards,
>
> Sergey
Thanks, Sergey (you'll be getting a near duplicate of this note, I
neglected to Reply-All to let the list see this post),
I have a build with SSL enabled already
unicon -features
...
secure sockets layer encryption
...
But I think I need to do a little more setup/configuring on my end.
https is not "supported" supported but it's available in the code. :-)
And yeah, for that little sample, a pipe would work as well.
p := open("curl -s https://sourceforge.net/projects/unicon/";, "p") |
stop("Cannot curl")
while write(read(p))
close(p)
For now, the plan is to get better at debugging the runtime and be able
to track which line is failing. Then figure out if it is a local
problem, or the platform, or something systemic.
Or, plan B, wait for the professionals to keep making things better and
supersede the reporting. :-)
So many things to explore... Oh, and Discussions are SourceForge are
turned on, so check out
https://sourceforge.net/p/unicon/discussion/
Be wary of the Allura SimpleMDE markdown editor everyone. It is in
Javascript, and bypasses things like FormHistoryControl (if you are like
me and end up clicking off page before hitting Post). The
FormHistoryControl browser addon is normally a lifesaver, but Javascript
editors and the ease of clicking back or a link to test something
leading to total webform data loss; it's like we're back in the save
early save often days of early PCs. I blame young people, those yet to
be born back in 1984. :-)
Have good,
Brian
> 18.08.2016, 06:46, "btiffin" :
>
>> Hello, everyone
>>
>> Clinton? Would you be willing to turn up the Discussion feature on
>> the
>> SourceForge project space? I've been managing the GnuCOBOL project
>> space there, and it's a pretty good forum, out of some few thousand
>> threads, and many tens of thousands of posts, we've had to deal with
>>
>> only 3 pieces of spam, and that's with one of the groups (Help
>> getting
>> started) open to anonymous, unregistered submissions.
>>
>> This is still pending, but the Pygments lexer is coming along as
>> part of
>> the docset I'm working on (long roadmap, 100 pages in and it's still
>> not
>> even a full outline, let alone getting into any nitty-gritties),
>> Syntax
>> highlighted listings make for a better conversation, in my humble
>> opinion, and thread web pages seem a little accessible than just a
>> mailing list. The highlighter won't be visible on the forge until I
>> get
>> the code accepted by team Pocoo for the Pygments layer, and then
>> it'd be
>> another wait until a source release makes it to the Allura team, but
>> it
>> will be in the not too distant future.
>>
>> I know it can split focus, but the project space there already hosts
>> the
>> mailing lists, so access to the archives will always be visible on
>> the
>> top-level menu of the Allura Unicon space, along with a Discussion
>> tab
>> (if you deem it worthy of turning on).
>>
>> Just curious, and a little bit hopeful. I find it more accessible,
>> even
>> with the bad rap the previous owners (Dice) tainted SourceForge
>> with.
>> The new owners (BIZX) seem quite a bit more concerned about
>> reputation
>> then scraping nickels with sleazy tactics. I see it as a fight with
>> good
>> speech to drown out the bad.
>>
>> Next up; how fixed is the 22 (MVS) and 13 (everybody else) column
>> showline tracer field widths? I find -t with 13 character filename
>> space way too short. I've tweaked my own copy or rdebug.r to go out
&
[Unicon-group] Discussion group on SourceForge and miscellaneous ramblings
Hello, everyone
Clinton? Would you be willing to turn up the Discussion feature on the
SourceForge project space? I've been managing the GnuCOBOL project
space there, and it's a pretty good forum, out of some few thousand
threads, and many tens of thousands of posts, we've had to deal with
only 3 pieces of spam, and that's with one of the groups (Help getting
started) open to anonymous, unregistered submissions.
This is still pending, but the Pygments lexer is coming along as part of
the docset I'm working on (long roadmap, 100 pages in and it's still not
even a full outline, let alone getting into any nitty-gritties), Syntax
highlighted listings make for a better conversation, in my humble
opinion, and thread web pages seem a little accessible than just a
mailing list. The highlighter won't be visible on the forge until I get
the code accepted by team Pocoo for the Pygments layer, and then it'd be
another wait until a source release makes it to the Allura team, but it
will be in the not too distant future.
I know it can split focus, but the project space there already hosts the
mailing lists, so access to the archives will always be visible on the
top-level menu of the Allura Unicon space, along with a Discussion tab
(if you deem it worthy of turning on).
Just curious, and a little bit hopeful. I find it more accessible, even
with the bad rap the previous owners (Dice) tainted SourceForge with.
The new owners (BIZX) seem quite a bit more concerned about reputation
then scraping nickels with sleazy tactics. I see it as a fight with good
speech to drown out the bad.
Next up; how fixed is the 22 (MVS) and 13 (everybody else) column
showline tracer field widths? I find -t with 13 character filename
space way too short. I've tweaked my own copy or rdebug.r to go out as
far as 26, (with a 5 digit line-number field, as I'm thinking that a
10,000 line Unicon program is not that far of a stretch. Large, yes,
but with some of the features in Unicon, programming in the large
doesn't seem to be a restriction). But, not knowing the ins and outs of
all the support utilities yet, I'm wondering what tracer support
programs that will break, or if you'd be up for accepting a patch
request? Thought I'd ask here before I get too used to the extra wiggle
room provided by 26 characters in the filename slot.
http://peoplecards.ca/unicon/statements.html#suspend (for example)
Next;
I have to do a little more testing, but I'm getting a segfault with
https access.
#
# Try https
#
procedure main()
w := open("https://sourceforge.net/projects/open-cobol/";, "m") |
stop("Can't")
line := read(w)
write("Line: ", line)
while write(read(w))
end
prompt$ unicon https.icn -
Parsing https.icn: .
/home/btiffin/inst/langs/unicon-svn/bin/icont -c -O https.icn
/tmp/uni21056032
Translating:
https.icn:
main
No errors
/home/btiffin/inst/langs/unicon-svn/bin/icont https.u -x
Linking:
Executing:
Run-time error 302
File https.icn; Line 6
memory violation
Traceback:
main()
open("https://sourcefo...","m";) from line 6 in https.icn
This is rev 4470 on a 64bit Ubuntu node, but I'll do a little more
digging before making a bug report. I may well have a borked openssl
config, blended with gnutls.
And lastly;
Thanks again for Unicon, Clint, Jafar, Steve, Robert and crew. Having
way too much fun, and the rabbit holes are a code spelunker's delight.
Next few days will be getting used to all the neato tools that Robert
Parlett has written up. Deep, rabbits, Mmmm.
Have good, make well,
Brian
--
___
Unicon-group mailing list
Unicon-group@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/unicon-group
Re: [Unicon-group] Starting in on some fan documentation
On 2016-08-03 08:10, Sergey Logichev wrote:
> Hello Brian!
> I have got a very deep impression about your work! That's great! I
> mean http://peoplecards.ca/unicon
> Unfortunately, I am not interested in COBOL, so can't comment this
> your massive masterpiece.
> I would like to ask your about Unicon Pigments? I've never heard about
> it. How it can be used and where?
> I myself use for Unicon/Icon source highlighting the Notepad++ for
> Windows. As turned on now there are a range of another solutions, for
> example, Geany, Textadept or SynWrite.
> I am Icon/Unicon fan during last 25 years :-)
>
> Best regards,
> Sergey
>
I'm going to be a day or two, before I'd want to show anyone the
Icon/Unicon Pygments lexer, Sergey, but as soon as it's ready for beta
testing, I'll post a copy for the list.
Pygments is a Python utility, well integrated into DocUtils,
ReStructuredText, Sphinx doc gen etc.
Requires one small, one large change to get working. Highly dependent on
Python install path but if you use pip, and not distro repositories,
it'll be
~/.local/lib/pythonN.M/site-packages/pygments
Where N.M is python2.7 or 3.4 or what have you. From there
lexers/_mappings.py
insert a line for Unicon ala
'UniconLexer': ('pygments.lexers.icon', 'Unicon', ('unicon',),
('*.icn',), ('text/unicon',)),
(and one for Icon)
Then (which is where I'll be focusing some time over the next bit, is)
lexers/icon.py
And you start scratching your head on the best way to manage all the
regular expressions. And then you fight with colour schemes. :-)
Then when it passes sample testing, it gets submitted it to Georg Brandl
and Team Pocoo, then shortly after that it'll show up on any website
that uses Pygments (many) or other Python based systems.
As a for instance, on a SourceForge Bug report
~~~
::c
some c code
~~~
And the code listing will be highlighted on the bug report. That's
Pygments, 100s of lexers available already. And hopefully soon, it'll
accept
~~~
::unicon
some better code
~~~
On Wikipedia, it's
IDENTIFICATION DIVISION.
PROGRAM-ID. hello-world.
PROCEDURE DIVISION.
DISPLAY "Hello, world!"
.
To get the Pygments engine, which is called even from that mainly PHP
codebase.
Cheers,
Brian
> 31.07.2016, 12:56, "btiffin" :
>
>> Hello,
>>
>> I've started in on a documentation set for Unicon.
>>
>> Early, (very early) sample at
>> http://peoplecards.ca/unicon/index.html
>> and http://peoplecards.ca/unicon/unicon.html and PDF trial at
>> http://peoplecards.ca/unicon/UniconProgramming.pdf
>>
>> If this works out, and it looks like it will, I'd like to pester the
>>
>> good folk here for some accurate details on background, proper name
>> spellings, and other odds and sods, so I don't lie on the
>> introductory
>> pages, or miss anyone that deserves mention. (I hope I didn't
>> overstep
>> any bounds snagging that logo temporarily, as that is also one of
>> the
>> early questions, where to find approved art for third-party fan
>> docs).
>>
>> The Pygments lexer seems to be working out, but there is a lot more
>> work
>> to get all the details right, and those won't be right until I get a
>>
>> little more used to the ins and outs of Icon/Unicon syntax. It'll be
>> a
>> few days/weeks/.../ before the code will be in shape to submit to
>> team
>> Pocoo.
>>
>> As a little background, I've been working on a GnuCOBOL document for
>>
>> some 8 years now, it's just passing the 1,200 working toward the
>> 1,300
>> page mark. That document is homed on SourceForge at
>>
>> http://open-cobol.sourceforge.net/faq/index.html
>>
>> (We don't have a unicorn, we use Sire the workhorse as a mascot for
>> the
>> COBOL project)
>>
>> If the Icon/Unicon Pygments lexer gets approved, it should show up
>> as a
>> feature on SourceForge shortly thereafter; (writing the GnuCOBOL FAQ
>> was
>> where the COBOL syntax highlighting came from originally, as I
>> wanted
>> the listings in colour). It turned out to be a subsystem used on the
>>
>> forge, and it really does help put a snap on the Discussion forum
>> posts.
>> If you don't turn up Discussions, it'll still be there to
>> highlight
>> source listings in the trouble tickets, and the other places where
>> you
>> use SourceForge. But again, more work to do, and I haven't talked
>> with
>> Georg Brand
Re: [Unicon-group] Status of codebase versus documentation, and other thoughts
On 2016-08-01 17:06, p...@firefly.nlm.nih.gov wrote: > Go ahead. When I wrote the original code there were two distinct ways > of getting the popularity rating, each giving a different value. > > --Phillip Thanks, Phillip. A patch is in, with an updated output fragment, (Icon was listed at position 26, so it didn't seem quite right to limit the fragment to the top 20 or 25). Nice code by the way, a good learning exercise, and hopefully I didn't tarnish your good name with the patch. And yes, the talk page is full of chatter about how the rules should work, and questions about how accurate the counts are, given the various methods used. There will be another update soonish, to account for some of the names having Unicode characters now. Those code points bork the right and left field padding calculations. Have good, make well, Brian > > On Sat, 30 Jul 2016, btiffin wrote: > >> On 2016-07-30 14:38, Steve Wampler wrote: >>> On 07/30/2016 02:18 AM, btiffin wrote: >>>> And one last issue, the Rosetta Code entry for the Rank by >>>> popularity >>>> seems busted >>>> >>>> http://rosettacode.org/wiki/Rosetta_Code/Rank_languages_by_popularity#Icon_and_Unicon >>>> >>>> I think the output format changed, so that sample is only picking up >>>> the >>>> first 500 entries, and missing out on the continue page. >>> >>> Yes - some change to the input to the program definitely broke it. >>> It >>> should be >>> marked as broken (or removed!) until someone [uh, that'd be you?] >> >> If no one has objections, I'll post that code as an update. >> >>> replaces it with >>> a correct version. >> >> It corrects the pass, but I'll give everyone here a chance to yell >> stop, >> if the new code reflects badly on Unicon. :-) >> >> Cheers, >> Brian >> >> -- >> ___ >> Unicon-group mailing list >> Unicon-group@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/unicon-group >> -- ___ Unicon-group mailing list Unicon-group@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/unicon-group
[Unicon-group] Unicon around the world
If you were ever curious, and this is a very soft statistic, single point source, yada yada, bob loblaw. Downloads of Unicon from SourceForge, broken down by country. prompt$ curl "https://sourceforge.net/projects/unicon/files/stats/json?start_date=2000-09-01&end_date=2016-07-31"; | jq .countries [ [ "United States", 2488 ], [ "Spain", 671 ], [ "Germany", 400 ], [ "Russia", 331 ], [ "China", 223 ], [ "United Kingdom", 190 ], [ "India", 158 ], [ "France", 154 ], [ "Canada", 130 ], [ "Netherlands", 124 ], [ "Italy", 98 ], And a fairly smooth spread after that, that's just the top 10 out of 101 entries (some few being things like Satellite Provider). Have some work to do with advertising here in Canada it seems; we should be at least at the 240 mark, to match the 1/10th of the U.S. population ratio. Time to get busy. :-) Cheers, Brian -- ___ Unicon-group mailing list Unicon-group@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/unicon-group
[Unicon-group] Starting in on some fan documentation
Hello, I've started in on a documentation set for Unicon. Early, (very early) sample at http://peoplecards.ca/unicon/index.html and http://peoplecards.ca/unicon/unicon.html and PDF trial at http://peoplecards.ca/unicon/UniconProgramming.pdf If this works out, and it looks like it will, I'd like to pester the good folk here for some accurate details on background, proper name spellings, and other odds and sods, so I don't lie on the introductory pages, or miss anyone that deserves mention. (I hope I didn't overstep any bounds snagging that logo temporarily, as that is also one of the early questions, where to find approved art for third-party fan docs). The Pygments lexer seems to be working out, but there is a lot more work to get all the details right, and those won't be right until I get a little more used to the ins and outs of Icon/Unicon syntax. It'll be a few days/weeks/.../ before the code will be in shape to submit to team Pocoo. As a little background, I've been working on a GnuCOBOL document for some 8 years now, it's just passing the 1,200 working toward the 1,300 page mark. That document is homed on SourceForge at http://open-cobol.sourceforge.net/faq/index.html (We don't have a unicorn, we use Sire the workhorse as a mascot for the COBOL project) If the Icon/Unicon Pygments lexer gets approved, it should show up as a feature on SourceForge shortly thereafter; (writing the GnuCOBOL FAQ was where the COBOL syntax highlighting came from originally, as I wanted the listings in colour). It turned out to be a subsystem used on the forge, and it really does help put a snap on the Discussion forum posts. If you don't turn up Discussions, it'll still be there to highlight source listings in the trouble tickets, and the other places where you use SourceForge. But again, more work to do, and I haven't talked with Georg Brandl in a while, so I'm not sure how swamped he is, and it'll have to be submitted, approved, and then some delay before the Allura team will upgrade the Pygments install, as their schedules permit. As a bonus, Pygments is used on Wikipedia as well, so colour listings will work on those pages too, along with what might already be there for Geshi in MediaWiki. That's all beside the point at this stage. For now, I'd appreciate it if someone could drop responses on the Who's who of Unicon, and the When's whens, etc. Please feel free to critique and criticize, and/or tell me to halt. If it's ok, I'll be working on this for a while, and I like to post early and often, and I'm always up for being corrected. These docs will have a free license. But I don't usually put a license on posts until I feel that a work is ready for redistribution by others. If the Unicon project has a licensing preference, I'd like to hear about it, and I'll match to suit, as long as freedom free is part of the choice. Along with the ReStructuredText there will be Markdown pages and a Fossil repository of all the code listings I plan to pepper the document with, for people to pull from. Lots to learn, lots to polish, and it's already way too much fun. I never had a chance to work with co-expressions when I was using Icon back in the 80s, 90s, but I was mightily impressed experimenting with them today. So many features to explore. Thanks for Unicon, and once again, feel free to critique and/or yell at me. I do all my work using GNU/Linux, so this doc set will be focused from that point of view, if that means anything to anybody. Have good, make well, Brian Tiffin btif...@gnu.org P.s. I've updated the Rosetta code language popularity entry, so feel free to yell at me about that one as well. -- ___ Unicon-group mailing list Unicon-group@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/unicon-group
Re: [Unicon-group] Status of codebase versus documentation, and other thoughts
On 2016-07-30 17:00, Jafar Al-Gharaibeh wrote: > On Sat, Jul 30, 2016 at 4:19 AM btiffin wrote: > >> Hello, >> >> I was wondering if argument coercion is implemented, or if the docs >> are >> early? >> >> I can't get >> >> procedure testing(i:integer:1) >> write(i) >> end >> >> to work. >> >> try.icn:24: # "i": syntax error (247;366) > > This happens if you directly compile using icont, please use the > command "unicon" instead. Ahh, I figured it was a new person problem, and this seemed like the right place to ask. Thanks. > >> Are string form procedure calls supposed to work? >> >> s := "testing" >> s(4) >> >> Comes up with a runtime error 106. Again, just curious. > > add the following at the top of your source file to enable string > invocation which is not enabled by default: > > invocable all > > Cheers, > Jafar And it seems I have a little more reading to do as well, looking forward to it. Gem packed mining. Have good, make well, Brian -- ___ Unicon-group mailing list Unicon-group@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/unicon-group
Re: [Unicon-group] Status of codebase versus documentation, and other thoughts
On 2016-07-30 14:38, Steve Wampler wrote: > On 07/30/2016 02:18 AM, btiffin wrote: >> And one last issue, the Rosetta Code entry for the Rank by popularity >> seems busted >> >> http://rosettacode.org/wiki/Rosetta_Code/Rank_languages_by_popularity#Icon_and_Unicon >> >> I think the output format changed, so that sample is only picking up >> the >> first 500 entries, and missing out on the continue page. > > Yes - some change to the input to the program definitely broke it. It > should be > marked as broken (or removed!) until someone [uh, that'd be you?] If no one has objections, I'll post that code as an update. > replaces it with > a correct version. It corrects the pass, but I'll give everyone here a chance to yell stop, if the new code reflects badly on Unicon. :-) Cheers, Brian -- ___ Unicon-group mailing list Unicon-group@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/unicon-group
[Unicon-group] Status of codebase versus documentation, and other thoughts
Hello,
I was wondering if argument coercion is implemented, or if the docs are
early?
I can't get
procedure testing(i:integer:1)
write(i)
end
to work.
try.icn:24: # "i": syntax error (247;366)
I'm running a local build of rev 4430.
Just curious.
Are string form procedure calls supposed to work?
s := "testing"
s(4)
Comes up with a runtime error 106. Again, just curious.
And one last issue, the Rosetta Code entry for the Rank by popularity
seems busted
http://rosettacode.org/wiki/Rosetta_Code/Rank_languages_by_popularity#Icon_and_Unicon
I think the output format changed, so that sample is only picking up the
first 500 entries, and missing out on the continue page.
I have a local version that looks like
$define RCLANGS
"http://rosettacode.org/mw/api.php?format=xml&action=query&generator=categorymembers&gcmtitle=Catego↪ry:Programming%20Languages&gcmlimit=500&prop=categoryinfo";
$define RCUA"User-Agent: Unicon Rosetta 0.1"
$define RCXUA "X-Unicon: http://unicon.org/";
link strings
link hexcvt
procedure main()
cnt := create seq()
last := -1
every pair := !reverse(sort(langs := tallyPages(),2)) do {
n := if last ~=:= pair[2] then @cnt else (@cnt,"")
write(right(n,4),": ",left(pair[1],30,". "),right(pair[2],10,".
"))
}
write(*langs, " languages")
end
# Generate page counts for each language
procedure tallyPages(url)
/url := RCLANGS
counts := table()
continue := ""
while \(txt := ReadURL(url||continue)) do {
txt ? {
if tab(find("gcmcontinue=")) then {
continue := "&"||tab(upto('"'))
move(1)
continue ||:= tab(upto('"'))
}
else continue := ""
while tab(find("https://lists.sourceforge.net/lists/listinfo/unicon-group
