Re: [Unicon-group] Walk of file directory
Okay, thanks. It's been so long since I've programmed against the Windows
API. Definitely sounds like a bug in there. Pity we have to take that into
account.
Could I suggest a prefix based on some part of the current timestamp as
well as a random factor. That would do a fairly simple but scalable
namespace partitioning. I don't have any facility to test it, sorry, so
I'm just tossing ideas out here.
Wade.
On Sat, 24 Jan 2015 04:01:03 +1100, Jafar Al-Gharaibeh
wrote:
Wade,
_tempnam(dir, prefix) is provided by Windows, we just use it and it
turned not to be smart at all - at least on my Windows 7 machine.
However, our >code that uses it could be made smarter to always use
randomized prefix every time - that is one approach.
Thanks,
Jafar
On Fri, Jan 23, 2015 at 3:44 AM, Wade wrote:
Sounds like the _tempnam() function could be a lot smarter in creating
temporary filenames. Is that our function or is it provided by Windows?
Wade.
On Fri, 23 Jan 2015 20:13:17 +1100, Sergey Logichev
wrote:
Jafar,
I am very appreciate for your investigations! Actually, my Windows
%TMP% folder included ~135000 temporary files, so when I cleaned it my
run >>>time decreased from ~40 secs to ~20. And the very first open()
was instant, then its time increased as number of temporary files
increases too. My >>>proposal to purge all temporary files after
program finishes or instead use virtual storage at RAM, as on every
searched subdirectory is created >>>single temporary file. After very
short time TMP folder will contain a myriad of such files.
Nevertheless I confirm that number of threads practically do not
influence on execution time. Probably, it's the problem of "lazy
cleanup", as you >>>mentioned. Hope you could find solution. Compared
with Linux - Windows is quite a bag of different bugs! Which runs from
every holes :-)
Thank you,
Sergey
23.01.2015, 10:19, "Jafar Al-Gharaibeh" :
Sergey,
Thanks for the report. I had in mind to look at why we don't get
much speed up with more threads. I did look and found that the
>>>>main thread was grabbing most "new thread tokens" and not
recycling them fast enough. I have to tweak my algorithm to allow
>>>>quick cleanup and reuse of threads. I will do that when I get a
chance.
Now the second issue - and you've gotta love this!-, I was able to
confirm the slow open(). With the help of gdb and after spending
>>>>a couple of hours digging into the C code and the Windows API
calls, I found that the problem is in a call to _tempnam() to create
>>>>a temporary file name. The call was taking so long to finish. It
creates the tmp file under your system TMP folder (%TMP% on
>>>>Windows). I looked in that folder and found that it has more than
half a million files (~2.7GB)!It turned out that every time my
program runs, Windows was looping through that huge pile of tmp files
to find a name that doesn't >>>>exist so that it can give it to the
program. Of course I think most of those tmp files were generated by
my program during previous >>>>runs the last couple of days. As a
bonus, I discovered a memory leak in the process of tracking the
open() problem. I committed a fix for that leak. This is only
>>>>affecting Windows.
Short term solution: flush your TMP folder.
Long term: we will into ways to improve our tmp file strategy to
overcome the shortcoming of Windows API. This will come in a
>>>>later date! :)
Cheers,
Jafar
On Thu, Jan 22, 2015 at 4:43 AM, Sergey Logichev
wrote:
Jafar,
You've provided very interesting version of walk directory
algorithm. Communication with active threads' is a great thing!
I have checked your program under Windows 7. I was confused the fact
that execution time is negligibly depended on number of
>>>>>concurrent threads. I dug into and discovered that the first
operation open(s) takes near ALL execution time! 95% at least. Check
>>>>>it yourself when you slightly edit getdirs():
...
if ( stat(s).mode ? ="d" ) & ( tm := &time, d := open(s) ) then {
if n=1 then write(s," : ",&time-tm)
...
So, if first open() is so long then all other enhancements have no
sense. Please clarify if I am wrong.
Best regards,
Sergey
22.01.2015, 00:58, "Jafar Al-Gharaibeh" :
Here is a slightly tweaked/reformatted version. It now by default
auto-detect the number of available cores in the >>>>>>machine and
launch twice as many threads.
--Jafar
On Wed, Jan 21, 2015 at 12:17 PM, Jafar Al-Gharaibeh
wrote:
David,
I added a threaded solution @
http://rosettacode.org/wiki/Walk_a_directory/Recursively#Icon_and_Unicon
Please review/edit
Re: [Unicon-group] Walk of file directory
Sounds like the _tempnam() function could be a lot smarter in creating
temporary filenames. Is that our function or is it provided by Windows?
Wade.
On Fri, 23 Jan 2015 20:13:17 +1100, Sergey Logichev
wrote:
Jafar,
I am very appreciate for your investigations! Actually, my Windows %TMP%
folder included ~135000 temporary files, so when I cleaned it my run
>time decreased from ~40 secs to ~20. And the very first open() was
instant, then its time increased as number of temporary files increases
too. My >proposal to purge all temporary files after program finishes or
instead use virtual storage at RAM, as on every searched subdirectory is
created single >temporary file. After very short time TMP folder will
contain a myriad of such files.
Nevertheless I confirm that number of threads practically do not
influence on execution time. Probably, it's the problem of "lazy
cleanup", as you >mentioned. Hope you could find solution. Compared with
Linux - Windows is quite a bag of different bugs! Which runs from every
holes :-)
Thank you,
Sergey
23.01.2015, 10:19, "Jafar Al-Gharaibeh" :
Sergey,
Thanks for the report. I had in mind to look at why we don't get much
speed up with more threads. I did look and found that the main >>thread
was grabbing most "new thread tokens" and not recycling them fast
enough. I have to tweak my algorithm to allow quick >>cleanup and reuse
of threads. I will do that when I get a chance.
Now the second issue - and you've gotta love this!-, I was able to
confirm the slow open(). With the help of gdb and after spending a
>>couple of hours digging into the C code and the Windows API calls, I
found that the problem is in a call to _tempnam() to create a
>>temporary file name. The call was taking so long to finish. It
creates the tmp file under your system TMP folder (%TMP% on >>Windows).
I looked in that folder and found that it has more than half a million
files (~2.7GB)!It turned out that every time my program runs, Windows
was looping through that huge pile of tmp files to find a name that
doesn't >>exist so that it can give it to the program. Of course I
think most of those tmp files were generated by my program during
previous runs >>the last couple of days. As a bonus, I discovered a
memory leak in the process of tracking the open() problem. I committed
a fix for that leak. This is only >>affecting Windows.
Short term solution: flush your TMP folder.
Long term: we will into ways to improve our tmp file strategy to
overcome the shortcoming of Windows API. This will come in a later
>>date! :)
Cheers,
Jafar
On Thu, Jan 22, 2015 at 4:43 AM, Sergey Logichev
wrote:
Jafar,
You've provided very interesting version of walk directory algorithm.
Communication with active threads' is a great thing!
I have checked your program under Windows 7. I was confused the fact
that execution time is negligibly depended on number of >>>concurrent
threads. I dug into and discovered that the first operation open(s)
takes near ALL execution time! 95% at least. Check it >>>yourself when
you slightly edit getdirs():
...
if ( stat(s).mode ? ="d" ) & ( tm := &time, d := open(s) ) then {
if n=1 then write(s," : ",&time-tm)
...
So, if first open() is so long then all other enhancements have no
sense. Please clarify if I am wrong.
Best regards,
Sergey
22.01.2015, 00:58, "Jafar Al-Gharaibeh" :
Here is a slightly tweaked/reformatted version. It now by default
auto-detect the number of available cores in the >>>>machine and
launch twice as many threads.
--Jafar
On Wed, Jan 21, 2015 at 12:17 PM, Jafar Al-Gharaibeh
wrote:
David,
I added a threaded solution @
http://rosettacode.org/wiki/Walk_a_directory/Recursively#Icon_and_Unicon
Please review/edit as you see fit. (The source file is attached).
Combining recursion with thread might not be the >>>>>best solution
for this problem. If I were to put this in real use I'd go with an
iterative approach using master/workers >>>>>model. Anyway, this is
a excellent demonstration on how to use threads!. The key features
are:
1- How to create threads, limit their numbers, self-load balanced
(new threads are spawned at the time/place >>>>>where needed. One
they are done, they vanish allowing new threads to pop up in new
places in the directory >>>>>structure)
2- pass data and collect results to/from the threads using the new
language features.
Here is some sample output from my desktop machine (quad-core with
mechanical HDD. I will try another machine >>>>>with an SSD and see
if more threads scale better).the first argument to the program is
the target directory. The secon
Re: [Unicon-group] Problem opening file
On Fri, 18 Jun 2010 03:57:55 +1000, Steve Graham wrote:Thanks, Hugh. Forgot to include the most important thing!---Backslashes are your problem. They won't work in Unicon strings like that. Either double them or replace them with forward slashes.Wadeprocedure main() in := open("c:\users\steve\desktop\dd_va.go","r") | stop("Unable to open input file") out := open("c:\users\steve\desktop\dd_va2.go","w") | stop("Unable to open output file")while (line := read(in)) do { read(in) write(out,line)}close(in)close(out)a := 1end-- On Thu, 6/17/10, Hugh Sasse wrote:From: Hugh Sasse Subject: Re: [Unicon-group] Problem opening fileTo: "Steve Graham" Cc: "Unicon Mailing List" Date:
Thursday, June 17, 2010, 1:51 PMI'm not seeing the program in any attachments. Are you opening thefile to be altered (read + write access)? Under Vista 64 I've had thingslocked by anti-virus programs in a way opaque to me as a user, only whenthe AV has done its job does normality return. That's when I've beentrying to move, delete or otherwise write to the file.I don't know how to diagnose those further, so hope you get some otherhelp. HughOn Thu, 17 Jun 2010, Steve Graham wrote:> I'm running the following program on a Windows 7 x64 box. When I execute > > icont delete_spaces.icn> > I get the following:> > Translating:> delete_spaces.icn:> main> No errors> Linking:> > When I execute this:> > C:\Program Files
(x86)\Unicon\bin>delete_spaces> > I get this:> > Unable to open input file> > > I've checked security on the file and directory - They're owned by me and look okay.> > Probably a simple thing.> > Any help would be appreciated.> > > Steve> > > >
--
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo___
Unicon-group mailing list
Unicon-group@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/unicon-group
Re: [Unicon-group] HI! Is this list Unicon noob freindly?
On Wed, 21 Oct 2009 07:34:05 +1100, Sidney Reilley II wrote: > Are there any CGI-aware folks on this list, besides Jeffery? TIA.. I've done some fairly straightfoward CGI stuff. Have a look at http://yceran.org/qompose for my effort. It's about 300 lines of Icon and implements a fairly powerful, if very quirky, HTML template system. Wade. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Unicon-group mailing list Unicon-group@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/unicon-group
Re: [Unicon-group] Unicon interface to MySQL database
On Sat, 25 Jul 2009 23:39:00 +1000, Richard H. McCullough wrote: > Thanks for the info, Wade. > > 1) The GoDaddy situation is difficult. > a) I don't have root access. > b) There are no software development tools, e.g. make, gcc. > c) I have survived by copying my old versions of icont, iconx > from Red Hat Linux 7.3, and using PHP scripts to compile > my mKE programs. > d) I doubt if GoDaddy would agree to installing ODBC. In that case, your solutions are to switch away from Unicon, change your project to not use MySQL, or somehow create a way to call the database layer using PHP. > 2) I think the best possibility might be to use PHP to connect, > and figure out how to pass PHP info. to Unicon. > a) The book > "Beginning PHP and MySQL 5, From Novice to > Professional, Second Edition", W. Jason Gilmore, > Apress, 2006. > conjectures that PHP 5 would use their > own PDO interface to the "future" MySQL 5. > b) Is the use of PDO consistent with your statement > re "direct linking" to MySQL library? > c) I imagine that converting Unicon from ODBC to PDO > would be fairly easy. The MySQL client library is what you would use if you wrote a program in C that needed to talk to MySQL. PHP has two modules of its own written in C that do that. They provide functions in PHP such as mysql_connect(). There is a number of PHP modules that use one or the other of these to provide a better API abstraction. PDO is one of the latter. If GoDaddy provide a wodge of PHP that calls MySQL and says "use this, it'll work", then their PHP has the MySQL modules installed. I've worked with PHP for some years. If you have some PHP experience, I can probably help you start building a very basic shim in PHP for Unicon to talk to. Kind of as an aside, the network protocol of MySQL is documented. There is an expermental PHP module that uses it directly and I started writing a Unicon library that did, too. Unfortunately, the authentication step needs SHA1, which is where I left it. Wade. > - Original Message - > From: "Wade Bowmer" > To: "Unicon group" > Sent: Saturday, July 25, 2009 5:36 AM > Subject: Re: [Unicon-group] Unicon interface to MySQL database > > >> On Sat, 25 Jul 2009 10:21:10 +1000, Richard H. McCullough >> wrote: >> >>> I did a quick check on GoDaddy Linux host. >>> There is no /usr/lib/*odbc* file. >>> I think it's safe to say that GoDaddy's ODBC >>> interface [if it exists] is different from your >>> Linux system. >> >> There are two unix ODBC libraries, though I would expect to find either >> of >> them in /usr/lib. If you don't have root access, you will need to ask if >> they can install either iodbc or unixodbc, along with their dev >> packages. >> Unicon will compile against either. >> >>> I will try to discover how PHP connects on >>> GoDaddy system. >> >> PHP connects by directly linking to the MySQL client library. This is >> not >> the way Unicon does it. >> >> Wade. -- ___ Unicon-group mailing list Unicon-group@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/unicon-group
Re: [Unicon-group] Unicon interface to MySQL database
On Sat, 25 Jul 2009 10:21:10 +1000, Richard H. McCullough wrote: > I did a quick check on GoDaddy Linux host. > There is no /usr/lib/*odbc* file. > I think it's safe to say that GoDaddy's ODBC > interface [if it exists] is different from your > Linux system. There are two unix ODBC libraries, though I would expect to find either of them in /usr/lib. If you don't have root access, you will need to ask if they can install either iodbc or unixodbc, along with their dev packages. Unicon will compile against either. > I will try to discover how PHP connects on > GoDaddy system. PHP connects by directly linking to the MySQL client library. This is not the way Unicon does it. Wade. > Dick McCullough > http://mkrmke.org > - Original Message - > From: "Steve Wampler" > To: "Richard H. McCullough" > Cc: "Clinton Jeffery" ; "Paola Di Maio" > ; "Unicon group" > > Sent: Friday, July 24, 2009 8:17 AM > Subject: Re: [Unicon-group] Unicon interface to MySQL database > > -- ___ Unicon-group mailing list Unicon-group@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/unicon-group
[Unicon-group] Compling Unicon on 64-bit Ubuntu Jaunty Jackalope.
Hmm. Short answer: doesn't work. Long answer: 1. Lots and lots of warnings, mostly int/word stuff. 2. Some step in the make tries to delete a whole lot of .u* files that aren't there. 3. icont generates a buffer overflow and crashes during the build. I also (mistakenly) tried 32-bit before remembering my install was 64-bit. No, that doesn't work either, but that's because rswitch.s is not 64-bit code. :-/ This was all attempted from the ancient uni.zip that I downloaded as I can't get to CVS from my work machine. Maybe providing an updated version of that is something I can setup from my home box... Wade. -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge ___ Unicon-group mailing list Unicon-group@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/unicon-group
Re: [Unicon-group] read/write partition
On Sat, 07 Mar 2009 18:46:39 +1100, Clinton Jeffery wrote: > Hi Richard, > > Sorry, Unicon does not have any functions that read/write the partition > table, nor > any of the other applications you mention. It would be possible to write > raw > low-level > disk access functions using the dynamic loading and C-calling interface, > but > I am > not aware of someone who has done it yet. If anyone else in the group is > interested, > or has done something similar in Icon or Unicon, I'd love to hear about > it. Richard, if you're working in Linux, you should experiment with reading /dev/hda with the normal open() function. It is possible to head the parition table with normal file reading tools like head and cat, so I imagine Unicon would also succeed. It's just up to you to decode it (remmeber strings start at [1] in Icon! I've fallen foul of that discrepancy decoding niche filesystems in Unicon...). :-) n Fri, Mar 6, 2009 at 11:34 PM, Richard H. McCullough > wrote: > >> I'm trying to set up boot programs for Linux. >> Does Unicon have any special functions that >> read/write partitions? i.e., how can I read/write >> inodes, boot programs, partition tables, etc. >> that are not files in the file system. >> -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Unicon-group mailing list Unicon-group@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/unicon-group
[Unicon-group] Re: unicon progs repository ...
Steve Wampler writes: As much as I dislike perl personally, I *very much* like being able to type: perl -MCPAN -e "install PACKAGE-NAME" which makes using perl much easier. Much though it will make people cringe, this sort of request is really asking for IPL to be pulled out of the uni.zip file and made into a repository like CPAN or PEAR. And that's probably not that bad an idea. Wade. --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ Unicon-group mailing list Unicon-group@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/unicon-group
[Unicon-group] A discovery about (Un)icon's VM.
I recently had cause to test out some check-digit algorithms for a webapp. For various reasons, I did these experiments in Icon. The test involved calculating a check-digit for several million numbers in sequence and tabulating the statistical spread. Icon was perfect. However, the webapp in question is in PHP. So in a spirit of curiosity, I rewrote the test program (about 70 lines) in PHP and did some simple tests. I was surprised to discover that the Icon version was something like three times as fast as the PHP version! (Both languages were compiled from source, BTW.) What's nearly as important is that I wrote the thing in the "obvious" way, so there were no fancy Icon tricks. The only two things that were a bit messy to translate were two every clauses and some is-not-null operators in the setup. If you're curious, you can get the two programs here http://yceran.org/~wwb/icon/custno.tar.bz2 (~1.5k). Wade. --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ Unicon-group mailing list Unicon-group@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/unicon-group
[Unicon-group] Re: Unicon on .Net
Sudarshan Gaikaiwari writes: If the existing users of Unicon express interest in a .NET port I am sure that progress can be made on this front. It's Unicon's future so please vote ;-) Indeed. I would vote that the current Ucode VM stay in C. This would avoid Unicon/Icon from acquiring a dependance on .NET or Mono. OTOH, a translater that could take the Ucode for running it in .NET/Mono could be a good thing. If memory serves, isn't this how the Java compiler works? Put another way, .NET/Mono capabilities would be interesting and useful, but should not mandatory. I would prefer we see what Perl and PHP are doing (C API, Apache, etc.) and go that direction. Whilst the .NET/Mono goals are, from a technical viewpoint, noble and worthwhile, you cannot ignore the fact that it is Microsoft's baby. I don't want to play there: in my experience, Microsoft environments have a bad habit of being only "good enough". And that's on a good day. Wade. --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ Unicon-group mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/unicon-group
[Unicon-group] Re: unicon binaries
Wendell Turner writes: Regarding your question about Debian, we'd certainly be glad to have binary package build scripts and/or a binary distribution for it, along with any source or makefile/configuration tweaks needed. The same goes for other platforms. :-) I'm looking into the rpm for Unicon, and am having some trouble with it. I can build and install the rpm fine, and with that installation can build and run programs using the v10 graphics references. However, I would like to use Robert's latest graphics routines, and they don't seem to get installed. (When I build and run Unicon locally in my own directory, everything works fine.) I think going from an RPM might be the wrong approach. Would it be better to start with the .deb for Icon and see if the Icon source tree in that can be replaced with the Unicon source tree? Part of the reason I say this is because the Icon .deb is in the official Debian repository, so we know it complies with the Debian policy. Wade. --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ Unicon-group mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/unicon-group
[Unicon-group] Re: shared library support & autoexec .icn
[EMAIL PROTECTED] writes: P.S. I happen to use Debian, any objections if I take the latest CVS and Debianise it? I'm sure Clint will say go right ahead. I was going to have a stab at it, but I picked up a different job recently and don't have the time anymore to try. Wade. --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ Unicon-group mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/unicon-group
Re: [Unicon-group] Vim
At 09:38 PM 10/11/2004, John Sampson wrote: Hello, Has there been any move to integrate Unicon or one of its ancestors with the text editor Vim? There are various incarnations of Vim that incorporate languages such as Perl, Ruby and Scheme. To some extent one can then use the language in question to write Vim macros. There is an old web page about integrating Snobol with Vim, but I think this would only work on a prediluvian setup. If you're referring to syntax highlighting, recent versions of Vim have an Icon mode that works. Wade. --- This SF.Net email is sponsored by: InterSystems CACHE FREE OODBMS DOWNLOAD - A multidimensional database that combines robust object and relational technologies, making it a perfect match for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8 ___ Unicon-group mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/unicon-group
RE: [Unicon-group] compiling unicon source on debian sarge
The uni.zip source distro compiles easily on Debian v3. I think I used the intel_linux configuration, but it was some while ago. I keep meaning to make a .deb but haven't gotten around to it yet. Don't spend as much time on a Debian box as I really should. :-) Wade Bowmer At 06:35 AM 22/10/2004, you wrote: I have compiled Unicon for Debian a number of ways. The simplest is to use the alien command which will let you install from the rpm for Redhat. Cheers, Michael Meehan -Original Message- From: Clint Jeffery [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 19, 2004 11:08 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [Unicon-group] compiling unicon source on debian sarge Jonathan, The intel_linux configuration should build on most linuxen without much trouble, from either the CVS or uni.zip source distributions. The essential libraries are included in the distribution (GDBM comes to mind). We do get occasional hiccups when optional libraries (such as X11) are moved around and such, so if you have a build problem let me know and I'll help out. I'd be more than happy to put up some .deb files with current binaries; the Redhat binaries need updating also. On UNIX-based systems we go mainly from the source distributions. Clint --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl ___ Unicon-group mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/unicon-group
Re: [Unicon-group] Another fun puzzle from the snobol4 crowd...
At 08:11 PM 10/06/2004 -0700, Steve Wampler wrote:
On Thu, 2004-06-10 at 18:37, Majorinc, Kazimir wrote:
> Test for short strings!
>
> procedure is_OK(x)
>every i:=1 to *x-1 do
> if x[i]>>x[i+1] then fail
>return x
> end
>
> procedure forgotten_algorithm(x)
> repeat
> { x[?*x] :=: x[?*x]
> if is_OK(x) then return x
> }
> end
>
> procedure main()
> repeat {x:=read(); write(forgotten_algorithm(x))}
> end
Ok, *this one* I'm definitely not testing with the
2.2MB input file...
--
Steve Wampler <[EMAIL PROTECTED]>
You know, some of the posted entries remind me of the various Obfuscated
Code contests that come around. :-)
Wade.
---
This SF.Net email is sponsored by the new InstallShield X.
From Windows to Linux, servers to mobile, InstallShield X is the
one installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504
___
Unicon-group mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/unicon-group
[Unicon-group] Re: Unicon language features, extensions, etc. - re: Michael Meehan's response
I shall be replying to both Michael and David in this reply as I haven't had the time to really get into this in the last few days. David Gamey writes: I think Michael summarized things quite well. There have been many suggestions floating around and things have been quite a bit more active lately. --- The whole reference type discussion didn't sit well with me. It was much more than a semantics change. I think Michael hit the nail on the head with: Michael Meehan wrote: I think the suggestion of adding a reference type is a bad idea. I wasn't particularly interested in a reference type per se. I work with references almost daily in PHP and it's a language wart, but a necessary one because PHP copies everything unless you tell it not to. Icon and Unicon make reference copies to objects and structures, which is what PHP v5 will do. IME, the need to make explicit copies in this case is much much less pressing. If the motivation is to create a capability for pass by reference --- if this is an efficiency consideration it doesnâ??t make sense, as everything on the stack passed in the virtual machine is a de With references do we somehow avoid needing to copy aggregates? I actually had a situation where being able to pass a variable by reference in a function call would have been Really Nice. But I can't do it and have to resort to a horrible workaround. And it still doesn't work anyway. (But that program really needs re-structuring. So.) My solution was to permit non-aggregate values to be explicitly referenced just like aggregate values automatically are. Hence the direction of my queries. It was predicated on a number of assumptions I made about how the Icon runtime works and I tried to make the proposed changes as non-intrusive and unsurprising as possible. Altering the function call mechanism to enable variable reference would also achieve what I desired, no problems. Given, especially, that my original proposal would probably require a more complex change than I had envisaged, I may now go see if I can enhance the function call mechanism. (I recall some of the design decisions that were undone from Snobol to Icon. The gotcha's or what James Gimple called Snobol's Foibles. In particular the most dangerous and annoying were (1) variables defaulting to the null string and (2) unevaluated expressions. Tracking down errors in large programs because of variable name misspellings resulting in null strings being coerced into 0's or other forms was a huge problem that &null fixed. Create and coexpression semantics (even without their superior functionality) made far more sense than having a unary operator to prevent an expression from evaluating and cluttered the code often unnecessarily.) That is an interesting snippet of history. Thank you! Some aspects of the suggestions did seem intriguing and even useful, but I couldn't clearly see the price we'd pay for them. I am still left wondering if there is any useful middle ground here and what it might be. It is clear to me at least that this feature requires very careful evaluation. What is the real problem we're trying to solve here? Are there better ways to spend the effort? If it is performance, then threads and other language support would provide huge potentials for performance improvements I'm not sure references would have the same benefit. Many serious performance problems I've seen in Icon/Unicon can be overcome by reworking the problem to use lists, records and other structures. The other criteria for trying to add this feature is that it would be a relatively small change on the source code. :-) I'm interested in knowing how Icon works inside so I could conceivably help maintain it. There is just a small matter of time and learning... I for one have always treated Unicon/Icon/Snobol types as being mostly like pointers but without all the bad baggage. My understanding of them is clear and I am rarely surprised. I would have to agree with that. Wade. --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id56&alloc_id438&op=click ___ Unicon-group mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/unicon-group
Re: [Unicon-group] Clues needed to the Unicon source code, please.
At 02:36 AM 13/02/2004 -0700, Clint Jeffery wrote: > If anyone has ready access to those notes, I would be interested in a copy. I will at least look this weekend and see if I can find anything. Shamim was also in that class, but he is even more busy than I am! Why am I not surprised that Shamim was in that class? :-) > How does it currently work when I assign a > list variable to another? Do the variable descriptors end up pointing at > the same value descriptors? Or is it more complex than that? Value descriptors end up pointing at the same location in the heap. Most simple variable descriptors only live on the stack long enough to identify the location to be assigned or whose value is fetched and used in an expression. Ah. Yes, that makes sense. Thank you very much for this. > I shall go looking for [the Icon Implementation Book]. I had assumed > it was no longer available, but hadn't actually bothered to check. Copies turn up in used bookstores from time to time, and it is available FREE in electronic form, thanks to the generosity of Ralph and Madge Griswold. I've found that, thanks. Should keep me busy for a few days! :-) Wade. --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click ___ Unicon-group mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/unicon-group
Re: [Unicon-group] Clues needed to the Unicon source code, please.
At 12:18 AM 13/02/2004 -0700, Clint Jeffery wrote: Wade, you've been getting some very interesting suggestions from the group, which I don't intend to try to out-do (!). I will mainly add that a similar reference concept was done as an assignment in a graduate course on Icon Implementation at U. of Arizona around 1989 or so. The implementation has changed quite a bit, but the design raised lots of issues, e.g. how to support ref(L[i]) or ref(t["this"]), etc. Notes from this course might be useful if I or someone else in that class could dredge them up. But, I am not offering to go looking for it just now, fifteen year old stuff might effectively be lost or unusable at this point. Thanks, Clint! It did seem odd that no-one else has tried to make this work, but I wasn't going to say that. If anyone has ready access to those notes, I would be interested in a copy. I can see that Michael and I would get to discussing ref(L[i]) in another message or two. :-) WB> I found the assignment code in runtime/oasgn.r but I can't immediately see WB> how I can tell it if a non-structure type is supposed to be referenced. In working with variables there are two operations you would need to keep consistent: assignment and dereference. Both of this operations start from variable references, which are descriptors with a pointer flag set, which point at other descriptors where an actual variable's value is stored. For variables X and Y to both produce descriptors which point at the same location, you would at least be *internally* (in the C code) introducing an extended pointer-like data type; a way to store in Y the fact that it is an alias for X; making Y basically a variable reference. But at the source language level one can avoid adding an explicit type if one wishes. As I mentioned in subsequent messages, I was interesting initially in making the current reference mechanism available to non-structures. It not only seemed like the easiest option, but to my way of thinking it fills in a "hole" in Icon's feature set. How does it currently work when I assign a list variable to another? Do the variable descriptors end up pointing at the same value descriptors? Or is it more complex than that? The blue Icon implementation book might be very helpful to you on this. It seems like the Variable reference flag in descriptors is the one you want to understand and extend or modify in order to implement a ref() operator. I shall go looking for that. I had assumed it was no longer available, but hadn't actually bothered to check. Wade. --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click ___ Unicon-group mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/unicon-group
[Unicon-group] Re: Clues needed to the Unicon source code, please.
Steve Wampler writes: On Thu, 2004-02-12 at 04:29, Wade Bowmer wrote: What I had in mind was a built-in function, ... a := ref(b) Hmmm, interesting idea, but... It cannot be done as a [builtin] function. Functions (along with procedures) have no special semantics in terms of the call - so by the time you get inside the function to build the reference, it's too late! It would have to be an operator. (And the changes to the lexical analyzer, parser, and semantic routines that that implies.) Sorry, yes, I meant an operator. I haven't gone delving into the lexing and parsing code yet. If Icon uses a standard lexer, it shouldn't be difficult. Even if it doesn't, there would have to be a table of some sort a new entry can be made in. It should only need to call a function in the runtime, much like copy() does. I found the assignment code in runtime/oasgn.r but I can't immediately see how I can tell it if a non-structure type is supposed to be referenced. (My initial thoughts were to have some other flag in the variable descriptor.) So then I thought we could have a new type that would do the trick (I haven't gotten as far as figuring out just how to change it back). But I can't find where the types are listed et al. You'll have to introduce it as a new type - you'll have to do *much* more than set a flag, so it won't begin to fit in the descriptor. And, adding the new type means you have to make sure it's handled appropriately *everywhere*. I don't think the source code was ever set up to make it easy to add new types (that's what records let users do - add new 'types'). Why can't I set/add a flag into the descriptor? The only thing that would look at it would be the assignment function in the runtime engine. Nothing else needs to even care. (Well maybe the &dump routine should.) Making a new type, though, yes, that would be quite a significant change. And, of course, the result has to 'fit' with the rest of the language... Indeed. What do you think about en-referencing variables containing non-structure values? Wade. --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click ___ Unicon-group mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/unicon-group
[Unicon-group] Re: Clues needed to the Unicon source code, please.
Michael Borek writes: Wade Bowmer <[EMAIL PROTECTED]> wrote: " " What I had in mind was a built-in function, probably called " ref(), that was the reverse of copy(). That is, instead of making " sure you had a value, it tried to make what you gave it a " reference. So that " "a := ref(b) " " ... would result in two names for the same variable, Is this to be similar to c++ references, Fortran pointer/target, or Ada access types? I don't remember Fortran or know Ada well enough. But it would be like PHP's references. Or, put another way, a way for two variable names to refer to the same value, whatever its type. I haven't given it any deep thought, but some things to think about may be: 1. Are you sure that 'ref' should revert to ':=' when given an expression rather than a variable? Two other options come to mind: a) fail if i) the 'ref' parameter isn't a variable name or ii) the expression doesn't return a LHS (e.g.: L[1] for a list L) b) create a reference to the value. At the moment, I wanted it to as analogous to copy() as possible. copy() doesn't fail or error if given a non-structure. OTOH, ref() could fail if given an expression, though I wonder if that would be useful. I suspect not. 2. What would/should be the result of 'x := ref(f())' where procedure 'f' is: a) procedure f() static w := return w end (Here, 'f() := ' changes the value of static var 'w'. Since 'w' is permanent, it's not unreasonable to have a reference to it.) Since the function is already returning a variable, it would not be unreasonable for x and w to now be the same variable. b) procedure f() local L := [1, 2, 3] return L[1] end (Here, 'f() := 23' doesn't cause an error, but has no observable effect. Since 'L' disappears when the call completes, it doesn't make sense to have a reference to it unless the call leaves 'L' for the GC. What happens to 'L[2]' and 'L[3]'?) Here the function is returning a value, so there's no point in taking a reference. Especially since the variable is going out of scope, anyway. 3. What happens if the referenced variable goes out of scope? E.g.: a) procedure f(x) local y := 1 x := y . : end called as 'a := f(ref(i))' That wouldn't be a problem because x (and i) get assigned the *value* of y. b) procedure f(x) local y := 1 x := ref(y)#<*** . : end called as 'a := f(ref(i))' Here, x is being dissociated from i and being reassociated with y. And since both x and y go out of scope when the function ends, there's no problem. Doing the reverse (i.e. y := ref(x)) is a problem that is already solved because Icon looks after this when throwing structures around. 4. Does the GC have to keep track of references? I hope not! :-) Well, not any more than it currently does. 5. Do we have to distinguish between 'ref' assignment and ':=', e.g.: b := 4 a := ref(b) # 'a' is implicitly a pointer? a := 5 # b = 5 a := ref(c) # what happens to the reference to 'b'? # does 'b' now refer to 'c'? Think littler. The operator := already knows how to do a reference assignment for structures. The goal of ref() is to give non-structures access to this functionality. That's all. In your code, line 2 makes a be the same variable as b. It's not a "reference". Line 4 modifies a to now be the same as c instead of b. To make all three be the same variable, you'd do c := ref(a) That would be handy and is something I have wanted to do. I wonder if this may not also allow something like: ce1 := create x | y | z ce2 := !f(a, x) # f returns a list longer than 2 while @ce1 := @ce2 and have x, y, and z assigned. Possibly. I'm not very good with co-expressions, but I think I know what you mean. " " Note, I've not spent more than about 30 minutes in the Unicon Well, that's about 30 minutes longer than I have :^) I also spend most of the 20 minute walk home from the train station thinking about it! Wade. --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click ___ Unicon-group mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/unicon-group
[Unicon-group] Clues needed to the Unicon source code, please.
Okay, first of all, Clint: the uni.zip file on the website compiles in Debian Woody r3 and passes all its tests. Finding which packages to get so things would compile was a bit of a guessing game (umm make, gcc, libc6-dev, xlib-dev, I think) but that was a Debian issue, not a Unicon issue. Secondly, I had an idea of how to add references to Unicon in a limited but still useful capacity. Unfortunately, I'm rather floundering in the source code trying to figure out which files I need to tinker with. What I had in mind was a built-in function, probably called ref(), that was the reverse of copy(). That is, instead of making sure you had a value, it tried to make what you gave it a reference. So that a := ref(b) ... would result in two names for the same variable, and of course: x := ref(z + 15) ... should be absolutely identical to: x := z + 15 The biggest use for this would be to pass variables by reference into functions. You can sort of do it now, by doing: p := [ x ] f(p) ... but you can't go back to using x after you make that call; you have to use p[1]. It would be so much easier if you could do f(ref(x)) ... then x would still be valid and the function f() could modify it, too. I found the assignment code in runtime/oasgn.r but I can't immediately see how I can tell it if a non-structure type is supposed to be referenced. (My initial thoughts were to have some other flag in the variable descriptor.) So then I thought we could have a new type that would do the trick (I haven't gotten as far as figuring out just how to change it back). But I can't find where the types are listed et al. Note, I've not spent more than about 30 minutes in the Unicon code. And it's late at night. And I'm sure there will be some possibly lively discussion about this. Thoughts? Clues? Wade. --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click ___ Unicon-group mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/unicon-group
Re: [Unicon-group] Re: Proposal for changing the parameter type and default value syntax...
At 07:57 AM 7/02/2004 -0700, Steve Wampler wrote: On Sat, 2004-02-07 at 04:51, Wade Bowmer wrote: > > Oh, of course. But a structure could be just copied. How does one know there's a structure? list(5) might be a user-defined procedure that does something entirely different. ... except that if it is evaluated once, then the runtime knows with 100% certainty whether it has a simple scalar or a structure. Then it's just like calling copy(). But this is superseded by discussion below. It means the same as: procedure f(a) /a := [x + 1] Ah, I think I see. The real issue is where, within the scope of the procedure definition for f(), is the above expression evaluated. [This is probably what Wade is getting at...] It's exactly what I'm getting at. :-) Consider, for example: procedure f(a:= [x+1]) static x := 1 this could be evaluated as (ignoring the illegal syntax): (1)procedure f(a) /a := [x+1] static x := 1 (2)procedure f(a) static x := 1 /a := [x+1] And (1) has three possible interpretations: (a) either the global or local x (remember: if there's no local declaration for x, it's still local if there is no global declaration), but not the static (b) the static variable x, but before initialization (on the first call - that is, use the current value of static variable x). (c) the static variable x, after initialization, even on the first call. I don't think other interpretations (initial value of global x found during 'prescan', for example - what if there is no global x - does this create one?) are really reasonable. I also tend away from 1a as being syntactically misleading. 2 is the same as 1a, so that leaves 1b and 1c as possibilities. Actually, option 1a excludes static variables whilst option 2 does not. [snip] My preference is that the evaluation order on a procedure call would be: evaluate parameter type and default value expressions, if any evaluate initial clauses, if any, on first call evaluate local variable initializations, if any evaluate procedure body i.e. 1b above. I prefer the default value expressions to be after the initial clause. Why? Because this would mirror how default variables are manually handled. (This would be your option 2.) Also, the initial section is executed just once wheras the default expression should be called every time a parameter needs defaulting when the procedure is called. It also provides a way for dynamic defaults, which is elegantly Iconish. :-) There is still the issue that the parameters haven't gone through their default checking before the initial clause is called. Whilst that is currently a problem when manual handling of defaults, it *could* be solved by early processing of a parameter's default *if* it is referenced in the initial clause. Which gives rise to possible code-ordering and dependancy problems if a parameter's default references a variable assigned in an initial section after another expression that references the parameter... So I think that is probably not a good idea. It introduces a possibly unpleasant surprise into the language. Wade, who should probably find his downloaded copy of the Unicon book instead of always relying on his printed Icon book. --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ Unicon-group mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/unicon-group
Re: [Unicon-group] Re: Proposal for changing the parameter type and default value syntax...
At 06:59 PM 6/02/2004 -0700, Steve Wampler wrote: Consider: Procedure f(x:=list(5)) you *have* to create a new list each time the call is f() - to not do so would be asking for trouble. Oh, of course. But a structure could be just copied. What I actually meant was: procedure f(a := [ x + 1 ]) ... means what, exactly? Which value of 'x' is used? The global variable initialized at prescan? The global variable when the procedure is first called? The variable in the scope of the call when the procedure is first called? The global variable on each call? The in-scope variable at each call? A local variable in the procedure? Wade. --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ Unicon-group mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/unicon-group
Re: [Unicon-group] Re: Proposal for changing the parameter type and default value syntax...
At 09:20 AM 6/02/2004 -0500, Michael Borek wrote: > I was going to ask why you'd put a default value into the call, but come to > think of it, I can imagine this might be useful. + I wasn't actually thinking of doing this and don't quite understand + what you mean #^) Perhaps you could expand on the topic? Actually, it's probably not that good an idea, now that I think about it. It would function very similar to... some_fctn( (some_expression) | default ) ... which clearly has no need of special notation. In other words, instead of the procedure itself setting null values to defaults, the actual call does it before making the call. Odd, I know, but potentially useful in API-building situations where helper functions are called. + I think we are better served by using the same notation for parameter + defaulting and binding I'll think we'll have to disagree. :-) Wade Bowmer <[EMAIL PROTECTED]> --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ Unicon-group mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/unicon-group
Re: [Unicon-group] Re: Proposal for changing the parameter type and default value syntax...
At 10:43 AM 6/02/2004 -0700, Steve Wampler wrote: On Fri, 2004-02-06 at 07:20, Michael Borek wrote: > > Please note that I wasn't suggesting that call-by-parameter-name be > included now! I just wish to point out that using '=' or ':=' would > require a syntax change should call-by-parameter-name ever be implemented. Why? They are different beasts both lexically and semantically. There would be no need to change the syntax of default value definition were call-by-parameter-name ever be added. > In addition, '=' is used for numeric equality and I don't believe should be > overloaded for assignment. With respect to ':='; formally, no assignment > is being done in the procedure declaration as there are no bindings in > existence until the procedure is called. That's true, but can't the same be said for the *entire* procedure definition? I guess I don't see much difference between: procedure foo(x:=1) and procedure foo(x) /x := 1 (especially since they are symantically identical - so sharing a common syntax seems pretty reasonable). That brings up the issue of when a default expression (as opposed to a mere constant) is evaluated: is it when the procedure is declared? First call? Or every call? Each has their merits and problems. > I think that '=>' helps to > reinforce the notion, in the declaration, that the assignment is deferred > to the call. But that breaks the syntactic and semantic 'link' with the above, and would, to me at least, confuse things even more *if* Unicon ever added call-by-parameter-name, since they are semantically different operations. (I'm not advocating call-by-parameter-name incidently - I think Clint is right. In fact, I've never been a fan of it [though it *is* fun to think about!] - that's forcing extra lanes on the namespace bridge between the calls and the definition of a procedure.) IME, call-parameter-by-name is a useful quirk, but it's not necessary. I've found need for it in PHP (and I've done rather more programming in PHP than in Icon, sad to say) but I can synthesize it or do without. I've not yet needed it in Icon/Unicon, however, and am not going to sulk at Clint's refusal to add it right now. :-) But whilst it's interesting to consider forward planning, I agree that call-parameter-by-name and default paramters really are semantically different operations with no lexical impact on each other. Wade Bowmer <[EMAIL PROTECTED]> --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ Unicon-group mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/unicon-group
[Unicon-group] Proposal for changing the parameter type and default value syntax... (fwd)
Okay, now to send it to the list... :-) --Forwarded message -- From: "Wade Bowmer" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] (Michael Borek) Michael Borek writes: I would suggest a syntax of the form: var[:type][=>defaultvalue] This provides all the benefits mentioned in the original posting (http://sourceforge.net/mailarchive/message.php?msg_id=6974026) as well as preventing any confusion with procedure calls of expression I've been more-or-less following the discussion and I like the idea of distinguishing between a type and a default value. But I thought the notation proposed was for *declaring* functions, not *calling* them. I was going to ask why you'd put a default value into the call, but come to think of it, I can imagine this might be useful. OTOH, a way of calling parameters by name would be more useful, but different. I'd prefer => being used to name parameters in that way. So: procedure form_field(type := INPUT_HIDDEN, name, value := &null, width := "") ... could be called: form_field(name => "edit_id") ... which would be the same as: form_field(INPUT_HIDDEN, "edit_id") Wade. --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ Unicon-group mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/unicon-group
Re: [Unicon-group] How to replace side effects efficiently?
At 11:34 AM 23/10/2003 -0700, Steve Wampler wrote: On Thu, 2003-10-23 at 11:08, Louis Kruger wrote: ... > I don't see any source of ambiguity here. This is equivalent to: > > yref := &xref > xref := &yref > write (yref) > > ... and then yref goes out of scope, and *xref becomes invalid. Agreed, bad example (I was thinking about how *xref would behave - should it dereference just one level (ala C) or all the way down to a non-reference type? I suppose the former would be the only sane way to go, as it avoids the problem I was seeing in the above code...) I think things might be clearer if we sorted out some notation... Icon already has a deference operator; it's a leading dot. But it doesn't have a reference operator and the popular & is already taken. There is already a unary operator that's a word instead of a character: "not". So I suggest "ref" for taking a reference. > > Languages like C and FORTRAN operate under a 'caveat emptor' > > philosophy that isn't appropriate for languages like Unicon. > > Which is why invalid references would have to be checked. This might > impose a performance penalty on the use of references, but that's > consistent with the design of other language features. Also agreed. People shouldn't assume that reference types are as cheap as they are in C. I would posit that PHP4 would be a better comparison. However, PHP comes from the other direction than Icon wrt references: when you want them you must explicitly do so (which can produce problems because PHP also uses references to implement global and static variables...). Interestingly, the still-in-beta PHP5 is a lot closer to Icon with structures and objects that do automatic references instead of a full copy. Having programmed in both languages to some depth, I like Icon's approach much better and clearly the PHP language designers think so. So far I've needed an explicit reference in Icon exactly once: and I found I could use a list. (Yeah, it was a bit ugly, but it seemed to work.) In PHP, I've got to stay on top of them and I really shouldn't have to. Wade Bowmer <[EMAIL PROTECTED]> --- This SF.net email is sponsored by: The SF.net Donation Program. Do you like what SourceForge.net is doing for the Open Source Community? Make a contribution, and help us add new features and functionality. Click here: http://sourceforge.net/donate/ ___ Unicon-group mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/unicon-group
[Unicon-group] Re: generators in LHS of assignment
Louis Kruger writes: It seems to me that a new feature like this ought to be introduced in a way thats both flexible and backwards compatible. Here's one way to do it: Have all undefined variables default to a value specified by &undef. By default, &undef = &null, so existing code works as expected. However, &undef can be reassigned by the programmer. In addition, the semantics of &null are left alone. No, this is a bad idea. As Steve Wampler said, it introduces scoping problems with global flags being used to control execution. I'm also strongly reminded of the &ANCHOR problem in SNOBOL4 which came to be regarded as a serious mis-feature in the language. (For those who don't recall, &ANCHOR controlled an aspect of string scanning. IIRC set one way, patterns had an implicit ARB at the start and set the other way, they did not. It was often tempting to toggle the variable as required, but this created *more* problems as program logic encountered patterns that expected it to be in one state or another without checking.) Introduce a new constant &bottom (the term is taken from ordered set theory) which compares "below" every value of every other type, so that &undef := &bottom every (!x>:=0) +:= 1 would increment every positive value by 1, and also set undefined values to 1 I like the intention, but &bottom, &top (or &omega) and &nil brings to mind a horrible problem of Visual BASIC where a variable can be Empty, Nil, Nothing or simply not set - and you often have to check for them all :-(. PHP has a similar, though lesser problem. Having unset variables behaving identically as if set to &null is a *big* advantage, IMO. Wade. --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Unicon-group mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/unicon-group
Re: [Unicon-group] automatic login with open(http) ?
At 04:26 AM 10/06/2003 -0700, Richard H. McCullough wrote: For those web sites that require member login, is it possible to pass username and password in the open(http) header? Generally, if a web browser can do it, then Unicon can do it. It's just a Simple Matter Of Programming. :-) In practice, there are several ways a site can ask for a member login. The first and probably the simplest uses an extension of HTTP called Authentication, which is documented in the RFC. AFAICR, it requires checking for a particular response that indicates an authentication is required, then supplying an extra header in future requests to the same web server with the encoded password. The next simplest is probably more common and involves a HTTP POST with the username and password in certain fields. Such pages usually return a HTTP Cookie which (obviously) would be sent in subsequent requests. This also requires a bit of reverse-engineering of the target page to know which fields to post! The third and probably the hardest to do in Unicon is the second behind an HTTPS page. That requires SSL and thus encryption... Wade Bowmer <[EMAIL PROTECTED]> --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Unicon-group mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/unicon-group
[Unicon-group] Re: Unescaping html values?
Clint Jeffery writes: For what it's worth, I would not be averse to splitting up cgi.icn into two modules, one that has html- and cgi- utility functions that are highly reusable, and one that has the cgi application framework. If someone wants to do that and share the results, that would be swell. :-) Okay, if no-one else needs/wants to do that, consider it on my ToDo list. :-) Wade. --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Unicon-group mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/unicon-group
Re: [Unicon-group] Unescaping html values?
At 02:08 PM 3/06/2003 -0700, Steve Wampler wrote: Is there anything in Unicon that takes a string and maps HTML character encodings back into the real world? That is, given: "ftp%3A%2F%2Fsolarch.tuc.noao.edu%2FSPMG_cdrom%2" the result is: ftp://solarch.tuc.noao.edu/FSPMG_cdrom/ I don't see anything obvious in there html.icn or cgi.icn in the IPL. cgiReadParse() in cgi.icn does what you want, but it looks directly at $QUERY_STRING. Look in http://yceran.org/qompose/qompose.icn for a version I modified that takes an argument. I did want to use cgi.icn for Qompose, but it was tricky modifying cgi.icn so that I could both use it the way I wanted and it would still work as it currently does. Wade Bowmer <[EMAIL PROTECTED]> --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Unicon-group mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/unicon-group
Re: [Unicon-group] RPMs
At 12:03 AM 12/03/2002 -0800, Rev. Shamim Mohamed D.D. wrote:
> > [Shamim writes about removing destroying our obsolete RPM's and
> > eliminating plans to provide RPM's in the future.]
>Brief *BSD plug: in contrast, if I set the env. variable PKG_PATH to a
>URL that has binaries (the *BSD equivalent of rpmfind.net) I can just
>say "pkg_add -v ${PKG_PATH}/package-name" - it will recursively
>install all dependencies. Something like debian's apt-get but even
>better, because packages and ports [built from source] know about each
>other so I can have a random mix of things installed as binaries and
>things I compiled myself.
This is theoretically a good idea, but in practice, automated dependancy
fulfillment is a bad idea behind a metered Internet link. Believe me in
this; it was most hair-raising doing a Scoop install
(http://scoop.kuro5hin.org/) and seeing it try to upgrade Perl! That's an
8Mb download, BTW, and I pay for my downloads by the Mb.
RPM's lack in this regard is, for me, a hidden blessing. OTOH, I
(personally) have no problem at all with a tarball, source, binary or
otherwise.
>Sorry for rambling. Anyway, the question for Linux is: which Linux?
>Which versions of the kernel and libc etc. are most popular? I have a
>spare machine that is only used to play NPR programs via RealAudio, I
>volunteer to install the blessed distribution on it and provide
>binaries.
RH6.2 used to be a good, widely-compatible target. That's Linux 2.2.16 and
glibc 2.1.3. With the current version of RedHat now being 7.2, this might
not be so anymore, but it's a start.
2c deposited.
Wade Bowmer <[EMAIL PROTECTED]>
"All around me are nothing but fakes
Come with me on the biggest fake of all!"
___
Unicon-group mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/unicon-group
Re: [Unicon-group] Timezone
At 06:32 PM 18/01/2002 -0600, Thomas Christopher wrote:
>You might look at how the Python library handles times (including
>time zones). I've attached their html documentation page.
Having just a productive 5 minutes discovering in the Unicon manual how
many other time/date functions there are that Icon doesn't have, I strongly
suspect Unicon needs a better complement of time/date functions (there's no
equivalent apparent to Unix's mktime(), for instance). However, having also
just spent a week, on and off, working with time/date manipulation
functions in C and PHP, I think Unicon would be best served with a
time/date class that you can setup with a string (e.g. &dateline), number
(e.g. &now) or possibly a table (think tm_struct) and can be modified with
and can return any of the same upon request.
Timezone should naturally have at least two representatives in a
table-representative of a date-time-stamp: name and offset. This is what
Clint proposed adding to &dateline and is what Unix's strftime() does with
a %z.
I noticed that PHP - and Python, too (thanks Thomas) - seem to burden
programmers with the raw C calls, even though both languages have better
native types to work with than C and could have built something easier to
use on top of them. I also know the IPL has a collection of date/time
functions. Perhaps they need updating...
http://yceran.org/stuff/files/datetimeclass.icn is a first attempt at a
datetime class for Unicon. I've only checked it compiles ('twas a busy day
today). Feel free to modify/improve/incorporate into the IPL/point out
someone's already done one/etc. I pinched two routines from
ipl/procs/datetime.icn so I don't know how it handles out-of-range values.
I had in mind to add some methods like addMonth but haven't gotten to it
yet. And asString should know about country-types, if possible.
Wade.
>---
>Thomas W. Christopher, [EMAIL PROTECTED]
>http://tc.toolsofcomputing.com --- books (through Prentice Hall PTR):
>High-Performance Java Platform Computing, ISBN: 0130161640
>Web Programming in Python, ISBN: 0-13-041065-9
>Python Programming Patterns, ISBN: 0-13-040956-1
>
>
>
>
>- Original Message -
>From: "Clint Jeffery" <[EMAIL PROTECTED]>
>To: <[EMAIL PROTECTED]>
>Cc: <[EMAIL PROTECTED]>
>Sent: Friday, January 18, 2002 3:12 PM
>Subject: Re: [Unicon-group] Timezone
>
>
> > OK, let's pretend for a moment that we own the language and can add
> > anything we want to it. :-)
> >
> > What should our portable timezone information look like at the language
> > level? Should one of the existing keywords include timezone information?
> > Should there be a new keyword? Are there a standard set of strings
> > worldwide for this?
> >
> > I have not studied how to get the information under Windows, although I
> > suspect it will be moderately easy, and that it might involve a call to
> > GetTimeZoneInformation().
> >
> > Clint
> >
> > ___
> > Unicon-group mailing list
> > [EMAIL PROTECTED]
> > https://lists.sourceforge.net/lists/listinfo/unicon-group
> >
Wade Bowmer <[EMAIL PROTECTED]>
"All around me are nothing but fakes
Come with me on the biggest fake of all!"
___
Unicon-group mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/unicon-group
Re: [Unicon-group] operator
At 06:40 PM 12/12/2001 -0600, Federico Balbi wrote: >How difficult would it be to implement the (ternary?) "? :" operator in >Unicon? It could be pretty handy in some situations, especially for C >lovers :-) I'd rather not acquire it. C has ? : because if...then is a language construct, not an operator. As Clint mentioned, Icon's if...then already works where C programmers must descend to ? :. Wade Bowmer <[EMAIL PROTECTED]> "All around me are nothing but fakes Come with me on the biggest fake of all!" ___ Unicon-group mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/unicon-group
[Unicon-group] Qompose documentation updated.
Okay, Qompose http://yceran.org/qompose now has a tutorial added and a few small bugs fixed. Wade. ___ Unicon-group mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/unicon-group
[Unicon-group] HTML template app in Unicon.
I just thought I'd announce I've written myself a neat little HTML templating language with Unicon. It's called Qompose and you can see it at http://yceran.org/qompose/ including source code (it's about 280 lines including comments). It was an interesting exercise to write it. I plan to extend it soon, hopefully taking advantage of Unicon's ODBC support. Wade Bowmer. ___ Unicon-group mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/unicon-group
Re: [Unicon-group] ODBC under Unix
At 09:02 AM 2/10/2001 -0500, Federico Balbi wrote: >Hi Wade, > ODBC flag in the open functions is "o" and not "q" (PDF book has a >typo). I do not think the Linux binaries have ODBC built-in. You should >build your ODBC unicon yourself using gcc and the make scripts provided in >the unix config directory. Building from source is not scary. I was a bit disappointed the .rpm didn't have it but Clint said he intends to remedy this eventually. >The last revision of the interface uses: > >- f:=open(.."o"..) to open an ODBC connection >- fetch(f) to fetch a row >- sql(f,command_string) to send SQL statements to the server >- close(f) to close the connection Yes, I like this better than dbopen etc. >dbopen, dbfetch and dbclose are obsolete and got removed from my page. >Some links at unicon page may still be outdated though. We'll try to fix >it asap. > >I presume you also installed an ODBC driver for PGSQL right? Yes, but the documentation for configuring it is extremely opaque. I have no idea if I've got it right. I was hoping to use Unicon to test it worked, but obviously that's not easy right at the moment. >I am not sure when you visited my page. I am updating the information at >http://www.cs.utsa.edu/~fbalbi/unicon I checked your page yesterday. It's linked from http://unicon.sourceforge.net/ Wade. ___ Unicon-group mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/unicon-group
Re: [Unicon-group] ODBC under Unix
At 12:56 AM 2/10/2001 -0600, Clint Jeffery wrote: >[Wade asks about ODBC support under Linux] > >Unfortunately, at present the Linux binary distribution does not have ODBC >built in to it. ODBC is not exactly standard on UNIX, perhaps Federico >could tell us what we'd have to ship in order to safely include it as >standard in the Linux binary .rpm. Ah. Okay. Thanks. ___ Unicon-group mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/unicon-group
[Unicon-group] ODBC under Unix
Could I have some direction here, please. I would like ODBC to work in Unicon and I think I've got all the bits together, but Unicon is giving me an odd error. 1. I'm on RedHat 6.2 2. I'm using PostGres. It has a much nicer CLI client than MySQL. 3. iODBC is installed. 4. All access is entirely local. 5. open(..., "q", ...) [as per the .pdf] fails at runtime with a "dbm database expected" error 6. open(..., "o", ...) [as per Frederico's web page] fails at runtime with a "invalid second argument to open" error 7. dbopen(...) [well, I thought it was worth trying] fails with a "procedure or integer expected" error showing it's not defined. 8. I'm using the 10.0 beta binary of Unicon. 9. I think I have the odbc.ini files correct, but there are no tools I can find to test them. I intend to try from my Windows machine, though. 10. The target database exists. What am doing wrong? Is ODBC not provided in this binary? Wade. ___ Unicon-group mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/unicon-group
Re: [Unicon-group] Re: Mod_Unicon?
At 10:05 PM 26/09/2001 -0700, Shamim Mohamed wrote: > >> Something to think about: the various phases of serving an HTTP > >> request. > > > 1. server initialization. > > 2. connection received. 3. HTTP command received. > > 4. Headers returned. > > 5. Content returned. > > 6. Connection closed. > > 7. Post-connection processing. > >Seems to me that returning headers and content is effectively the >return value from the handler in phase 2/3, eh? That would be one way of looking at it, yes. >The other APIs (Apache and NS) define phases to do stuff like >authentication etc. Do we want support for that? Hmm. Might be worth considering. It also occurred to me that there are some sub-phases between 3 and 4, to do with converting a URL to a filename. I know from the mod_rewrite docs that Apache has some hooks at that point. >Do we want to tie it to Apache (in which case we can talk about things >like htaccess, logging, integrating with httpd.conf etc.) or make it >general? I think some of those could probably be suitably abstracted anyway, but not having used any other web server than Apache (IIS doesn't count), I don't know. Wade. ___ Unicon-group mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/unicon-group
Re: [Unicon-group] Re: Mod_Unicon?
At 02:06 PM 24/09/2001 -0700, Shamim Mohamed wrote: >There is some discussion floating around about passing env. variables >etc. to a socket server based app. server. I think that's a huge can >of worms and should be avoided. CGI is a hack that needs env. variables >because of its "external program/stdin+stdout" model. An intelligent >design would do something like invoke callback procedures (whether >linked in a la Apache DSOs or part of an app server in a sister process) >for various "phases". I was going to look at implementing a FastCGI module for Unicon. FastCGI is not a wonderful solution, but it is *a* solution and a working one at that. The protocol is documented, so I just have to go coding and make it work! :-) >Something to think about: the various phases of serving an HTTP request. Maybe we could start with this: 1. server initialization. 2. connection received. 3. HTTP command received. 4. Headers returned. 5. Content returned. 6. Connection closed. 7. Post-connection processing. Phases 2 and 3 could be combined, perhaps. Wade. ___ Unicon-group mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/unicon-group
Re: [Unicon-group] cgi module patch(s)
At 12:34 PM 11/09/2001 -0600, Clint Jeffery wrote: >Wade, > >I like your ideas. Backward compatibility is a good thing, so if you really >can't stand (or fix) cgi.icn's main(), maybe we should move non-dependent >library functions into a cgilib.icn that is linked by cgi.icn. What is it >about cgi.icn's main() that you object to? Yes, I agree, cgilib.icn and cgi.icn would be a better idea. The main() in cgi is not as flexible as I would like WRT to HTML. For instance, there is a tag I usually put in my hand-coded documents, and for XHTML there's an tag, too. Both of these go before the tag. By the same token, it forgets about other stuff that can go into the section, such as stylesheets and meta information. These, I was going to add support for, though. But the principle problem I have with cgi.icn's main() is that sometimes you want your code to generate *everything*. I'm currently building an HTML template script in Unicon that has this requirement because all the HTML is specified in template files. Have a look at http://z.iwethey.org/forums/render/content/show?contentid=7992 for some information I posted on an IT web forum I'm part of. For simple stuff, cgi.icn's main() is fine and I'll probably use it. Just not this time. :-) >You can send your additions/improvements to the list, or you can send them >to me for review. Either way, accepted contributions eventually make their >way into the CVS repository and thence into the source and binary >distributions. I would suggest posting whole files to a web site if you >have one, and announcing their location on the list. Okay. I'll put them up on my web server. Wade Bowmer. ___ Unicon-group mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/unicon-group
[Unicon-group] cgi module patch(s)
I'd like to update Unicon's CGI module in the following ways: 1. Update the few tags in it to XHTML standards. This means making all HTML tags lowercase and changing the closing > of non-container tags to /> (so is ). 2. Move main() into another module (suggestion: cgimain) so that if you want the cgi module functions but don't need what cgi's main does you can. I was also thinking of extending it a bit so even if you do use it you can specify a few more exotic things like stylesheets. I know this will break stuff; if that's a problem we could leave main() in cgi and move the rest of cgi to another module that cgi then links to. 3. I also want to create some cookie processing routines. Does someone need to approve these? And do you want whole updated files or patches? And do I post them to the list? Wade Bowmer. ___ Unicon-group mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/unicon-group
Re: [Unicon-group] Mod_Unicon?
At 10:06 PM 10/09/2001 -0700, Steven E Lumos wrote: >Wade Bowmer <[EMAIL PROTECTED]>: > >No, I realize that. The application server idea also has the problem of > >just how do you pass the necessary pieces of the CGI environment over > >there. I have an idea how to do that modelled on how ESMTP extended > >attributes work, but I haven't tried to code anything yet. It's tempting to > >try to come up with a CGI v2 type of spec, in fact. (-: > >I don't have any experience with it, but isn't this what FastCGI is >for? Ah hah... I'd say so yes. I had heard of this a long time ago but never chased it up. Well, that's the idea of mailing lists - sharing knowledge. Thanks for the kick to the head. :-) Wade. ___ Unicon-group mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/unicon-group
Re: [Unicon-group] Mod_Unicon?
At 09:14 AM 10/09/2001 -0700, Steven E Lumos wrote: > >Is anyone interested in making a mod_unicon or mod_icon for Apache, much > >like there's a mod_php and a mod_perl? Or, should I say, anyone interested > >in helping? I'm not sure quite how to tackle this. > > > >Wade. > >I wrote a simple Apache module and it's not too bad if you read the >documentation and sample code carefully. The first question though is >what you intend mod_unicon to do. Things like mod_php and (I think) >mod_ruby seem to be mainly intended to keep the interpreter in memory. That's close to what I had in mind. I was really after a method for a Unicon CGI program to be called or resumed after it's already initialized what it needs to, for instance, reading (possibly extensive) configuration files or creating ODBC connections. OTOH, there isn't a lot of urgency in doing this yet - the site in question is not going to get 20 hits a second; at the moment, it will be lucky to get 20 hits a day. >But mod_perl actually exposes the entire Apache API, so you can write >modules in Perl rather than just executing code embedded in web pages. >The application server method that was suggested won't let you do >that. No, I realize that. The application server idea also has the problem of just how do you pass the necessary pieces of the CGI environment over there. I have an idea how to do that modelled on how ESMTP extended attributes work, but I haven't tried to code anything yet. It's tempting to try to come up with a CGI v2 type of spec, in fact. (-: > From the other messages, it sounds like that isn't needed, but if >anyone does start looking seriously into an Apache module, my advice >is to use axps and dynamic loading. It's much easier than what you >have to do to statically link a module into Apache. More jargon to learn... :-) But thanks for the ideas. ___ Unicon-group mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/unicon-group
