Re: pilog dcg with args
(de sub? (Pat Str) (and (match (cons '@ (conc (chop Pat) '@)) (chop Str)) Str ) ) or (de sub? (Pat Str) (setq Pat (chop Pat)) (and (seek '((L) (head Pat L)) (chop Str) ) Str ) ) (is there a better (shorter, more elegant) way?) If it's about checking single characters, why not just: (de sub? (Ch Str) (member Ch (chop Str) ) so rewriting this: (or (= X ,) (= X .) (= X ?)) as (sub? X ,.?) would work just fine.
Re: Pico Lisp and Emacs Lisp
On 03/24/2011 08:39 AM, Thorsten wrote: Hallo, it seems to me that elisp and picolisp are close relatives in the lisp familiy, Yeah... they both use parens and dynamic binding... and I wonder if it would be possible to convert elisp code to picolisp code - and how difficult this would be? No way, raw translation won't do any good. Porting is required. There have been apparently successful attempts to convert elisp to scheme (http://www-pu.informatik.uni-tuebingen.de/users/knauel/selc-ifl.pdf), and scheme is very different from elisp. Not so different if you leave aside the #t #f '() and dynamic binding. (it would be more troublesome to port stuff from scheme to elisp) I was thinking about `refactoring` the text in *.el files to a syntax that picolisp can understand, but that might be too naive. All the (1800 ?) primitive C functions in elisp were problematic when porting elisp to scheme, but maybe thats not the case with picolisp. Of course the thousands of buffer functions etc are meaningless in picolisp, Deppends on what you want to do, but a LOT of elisp code (I'd say most of it) deppends on buffers (as in data type/structure). If you mean buffers as in frames/windows, yeah.. but there's very little of it AFAIK. since there are no buffers in the gui framework. But maybe one could connect the conkeror webbrowser (http://conkeror.org/), a fine javascript browser modeled closely after emacs, to the gui framework of picolisp and map the emacs buffer commands etc to the related conkeror concepts (it has buffers, keymaps ...). Then suddenly many of those emacs modes and libraries would make sense in picolisp, and with more than 1 million lines of elisp code available the claims that 'picolisp has no libraries' would stop. They wouldn't be modeled the picolisp way, nor they'd be specific to it. Besides... most of emacs is about modes. Most about modes is parsing, highlighting and indenting (maybe some smart stuff like applying overlays to hide stuff like in html-mode) and a few macros and word-delimiters definitions. So.. what's there to port? Regarding conkeror.. I've used it for a year, but then moved to vimperator which I find to be quite superior in most aspects. All this would make sense if there was a picolisp-based-editor, and even if that were the case, it's not a good idea to mass-rip stuff from emacs (since emacs is full of contradictions and different criteria) By the way, these kind of discussions are better in IRC (#picol...@irc.freenode.net) - Arm -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Wiki, logo
On Thu, 14 Jan 2010, Jon Kleiser wrote: On 1/14/10 10:30 AM, Boh Yap wrote: hi alex, I am the one that is impressed by what you have done.. PicoLisp. .. Hi Boh Yap, I think your logos are quite elegant. I have made some tweaks to the 3-armed variant lately, but they probably are not as elegant as yours. They can be seen here: http://folk.uio.no/jkleiser/pico/graphics.html http://folk.uio.no/jkleiser/pico/graphics2.html Wow, the second one looks good. It looks like one of those fancy garden sprinklers that spin. -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: PicoLisp at Ohloh
On Tue, 5 Jan 2010, Mateusz Jan Przybylski wrote: On Tuesday 05 January 2010 13:13:14 you wrote: On Tue, Jan 05, 2010 at 12:56:02PM +0100, Mateusz Jan Przybylski wrote: Ohloh has (experimental, but good enough) support for Mercurial. As an example, my another favorite project using Mercurial : http://www.ohloh.net/p/plan9port I don't think we can merge the entries. I'd propose to go with the first one, extend it with link to Google Code and remove (or rename mark as inactive) the later one. If Ohloh has native support for HG, wouldn't it be better abstain from using Google Code? I feel uneasy with that data octopus. Cheers, - Alex Support for reading from reporting about projects stored in external repositories, not hosting them. For example this neat statistic: https://www.ohloh.net/articles/php_eats_rails Given that Ohloh is owned by SourceForge (since this year), I don't see it providing *separate* repository hosting anytime near soon... Personally, I prefer googlecode instead of sourceforge. -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: Wikipedia
I'm not donating a fucken cent to wikipedia after this. On Mon, 4 Jan 2010, Robert Wörle wrote: Cheers All Here are my 5 cents to this. First about the spelling: The release version is named picoLisp. So i consider this the correct spelling coming from Alex directly. picolisp.org also uses various types of spellings. 2nd about the wiki people: gtf out of our way. Wikipedia was intended to be a open knowledge basis. You can look up any big company name there and there are even tons of refernce links into those companys. The simple fact of the GPL License of picoLisp counts against the commercial argument they made. So its all there and you can learn it , understand it (if !) and use it as the GPL says. I my opinion, if wiki people keep acting like that , then picoLisp doesnt need em anyway. There are tons of other ways to populate picoLisp. Rob Jon Kleiser schrieb: Cheer up, Alex! Without some of your articles being mentioned on Lambda the Ultimate back in 2007, I would probably not have heard of PicoLisp. I'm glad I got to know it. In my opinion PicoLisp is a shining gem, and by studying it one can learn a lot about different and clever ways to do programming. I now took a look at this: http://en.wikipedia.org/wiki/Picolisp Two things made me unsure if this was the same Lisp: It was originally developed on the Apple Macintosh. Wow! ;-) And then the spelling: PicoLisp, no space. It used to be Pico Lisp, but you've obviously changed it. (I just wish it wasn't Picolisp, lowercase l.) Let's try to make that article stick! If we succeed, I'll make another try at donating some money to Wikipedia. Keep up the good work! ;-) /Jon On 1/4/10 2:01 PM, Alexander Burger wrote: On Sat, Jan 02, 2010 at 10:05:06PM +0100, dexen deVries wrote: sources', which seems to translate to press, including electronic. Or at le= ast=20 a few `high-profile blogs' etc. Best would is something peer-reviewed. OK, my last try is the article in the German magazine c't. I've put a link into the English and German versions. Besides this, I'm extremely frustrated. I think I wasted too much time on communicating (instead of using) PicoLisp during the last 8 years. From now on I'll concentrate on my own work. I won't write any articles, or propagate PicoLisp in any way. I'll answer questions in this mailing list, though. Cheers, - Alex -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: Transient symbol markup
On Mon, 16 Nov 2009, Alexander Burger wrote: Armadillo (tc.rucho) is implementing support for transient symbol markup also in his picolisp mode for 'emacs'. I would love to have it in 'vim' too, but have no idea if or how this might be possible. How about using emacs with viper+vimpulse? (almost full vim emulation) :-P -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: Bug or feature?
On Tue, 10 Nov 2009, Javier wrote:
Hello, I'm new to the list and Picolisp.
I tried this, and obtained a segfault:
: ('(1 2) 6)
Violación de segmento
But, if i try:
: ('(a b c) 6)
- NIL
I mostly understand why, but it was a surprise that Picolisp responded with a
segfault instead of an error.
Does this means that Picolisp doesn't check if a number is a function but it
does when it is a symbol?
In that particular example, the problem is that a number can't be used as
variables.
When you do:
: (de foo H
H)
: (foo 1 2 3)
- (1 2 3)
: foo
- (H H)
so you can also do:
('(H H) 1 2 3)
- (1 2 3)
If we take your first example and revert it to a 'de form we get:
: (de foo 1
2)
I bet you know what happens here; you are trying to use a number as a variable,
which is illegal - crash (besides it does not make sense anyway)
Regarding the error, checking for these things is an unnecessary overhead.
- Arm
Re: Picolisp Slogan? :-)
On Mon, 9 Nov 2009, Alexander Burger wrote: Hi Boh Yap, / /\ /__\__ / I also see a 'lambda' in there.. ;-) Hey, that's cool! I didn't notice that. It is especially interesting, as PicoLisp doesn't otherwise show an explicit existence of 'lambda' in the language. Hey, the lambda is in the other version. Remember, lambda it's an 'y mirrored in the horizontal axis. \ /\ /__\__ / There's the lambda :-) So that logo means: /\ /__\ -- 'p / + \ /\ -- 'λ (implicit) / \ + \ \ \ Or /Or/-- 'L (different variants) \__ /___ /__ = \ /\ /__\__ / I think It ended up being a nice candidate for a logo, don't you think? :-) But we don't have any slogan yet :-( - Arm
Re: onOff question
On Fri, 9 Oct 2009, Tomas Hlavaty wrote: Hi Alex, All functions ignore atomic CDRs of the last argument cell. You could also try (onOff A B . X), the 'X' will be simply ignored. so why is not NIL in the (onOff . NIL) ignored? ;-) zero arguments (as in 'onOff') are not to be expected, the function goes straight on and takes the first argument, which happens to be NIL in this case. So 'onOff' does not distinguish (nor even check) the difference between (onOff) and (onOff NIL) There is no practical reason to do so, because calling 'onOff' without arguments makes no sense. Remember, it is a non-evaluating function, and cannot be called in a less predictable way (e.g. being passed through 'apply', mappings etc.). Ok. I think that most functions in PicoLisp behave like this. Try 'list', for example: : (list NIL) - (NIL) : (list) - (NIL) It does not care to check for the first argument. 'list' is a good example where I find this behaviour rather strange. : (list) - (NIL) Here I would expect NIL and not (NIL). Any other lisp I know works this way and it also makes sense. I.e. the command says make a list of nothing (not even a NIL) and an empty list is NIL so this behaviour seems broken to me. Do you have any example or code in picolisp that takes advantage of this behaviour? Ugh, I also find that weird: : '()# Empty list - NIL : (list '()) - (NIL) : (list) # List nothing - (NIL) # I think this should be NIL I'm uncertain if '() is actually (NIL . NIL) so I'm not going to list the cons' examples. I know why this works this way. In pL's VM, every list is parsed until there's an empty CDR (retreiving CDR returns NIL). Since there are functions that MUST take at least one argument; when they are called with no argument, they will try to read NIL's CDR, and therefore use NIL as arguments, since (cdr NIL) - NIL Here are a couple of solutions for this issue, you pick: 1. Make it error when (cdr NIL) (increases complexity and decreases flexibility). 2. Make pL check on every step if the current argument is actually the last CAR (naive and maybe slow). 3. Make pL check the amount of arguments provided and return NIL if they are not enough for the function to do it's job. (slightly increases complexity) 4. Bury the topic. Regarding option 3, if there is a significant number of functions that would benefit from this, a compiler macro should be useful. This data could be listed together with the declaration header: (code 'doList 2 1) -- This means: Needs at least 1 real argument so (list) - NIL and (list NIL) - (NIL) Anyway, I just couldn't resist the temptation to try to implement solution nº 3, so I grabbed the sources, segfaulted the hell out of it when I tried to avoid repeating code, and after a long while of ERTCL (edit, recompile, test, cuss, loop), I decided to leave it like that for now, and ask for a revision. I'm attaching the working patch for the 'doList function.--- subr.l.~1~ 2009-09-30 09:24:22.0 -0300 +++ subr.l 2009-10-09 21:49:17.0 -0300 @@ -883,11 +883,49 @@ pop X ret +### Internal function ### +(code 'argLen 2) + push X + push Y + ld X E + ld E ONE # Counter + do + cmp X Quote + while eq + ld Y (X CDR) # Next cell + cmp Y X # Circular? + jz lengthT # Yes + ld X Y + atom X # Done? + jnz 10 # Yes + add E (hex 10) # Increment counter + loop + ld Y X # Keep list head + do + ld X (X CDR) # Next cell + atom X # Any? + while z # Yes + cmp X Y # Hit head? + jz lengthT # Yes + add E (hex 10) # Increment counter + loop +10 pop Y + pop X + ret + # (list 'any ['any ..]) - lst (code 'doList 2) push X push Y ld X (E CDR) # Args + call argLen # Args length + cmp E ONE # No args? + if eq # Right + ld E Nil + pop Y + pop X + ret + end ld E (X) # Eval first eval call consE_C # Cons with NIL
Re: Sum of digits
On Sat, 19 Sep 2009, Jon Kleiser wrote:
Hi,
I wanted to compare how to do sum of digits in Scala and Pico Lisp, and
to my surprise my Pico Lisp version was much slower than my Scala version.
Well, Scala is a compiled language, but I hadn't anticipated that big a
difference. My test input number was a rather big one: (2^100 + 3^200)^300
(#8776;1.885 x 10^28627)
My Scala code was like this:
def sumOfDigits(n: BigInt): BigInt = n.toString.map{ _.asDigit
}.foldLeft(0){ _+_ }
val big = (2:BigInt).pow(100)+(3:BigInt).pow(200)
sumOfDigits(big.pow(300))
- 128458
My Pico Lisp code was like this:
(de sumOfDigits (N)
(apply + (mapcar format (chop (format N )
(setq Big (+ (** 2 100) (** 3 200)))
(sumOfDigits (** Big 300))
- 128458
Could I have written the Pico Lisp code differently to make it faster?
1. avoid being redundant in the code, but it's not something that will make any
difference in speed here:
(de sumOfDigits (N)
(apply + (mapcar format (chop N))) )
# 'chop implicitly uses 'format, so there's no real reason to keep it there.
2. What's taking a long time here is not the 'sumOfDigits, but rather the
bigass number calculation and handling.
The bignum implementation was not intended to be.. *fast*, in the first
place. The implementation works with linked lists instead of arrays.
(setq Big (+ (** 2 100) (** 3 200))
Groso (** Big 300)
Venoso (format Big))
(sumOfDigits Venoso) # This alone should be *really* fast
So, what you'd really wanted to say in the original email is Hey, scala has better bignum
implementation than pL rather than Hey, scala does 'sumOfDigits faster than pL
(which is true, but derived from the first) ;-)
Solutions:
1. Use a C lib (like GMP) to do all the dirty work and then bring back the
result to pL to do the chopping and stuff.
2. To write a better bignum implementation for pL.
3. Cope with it(?)
--
UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: From Pico to JSON in the client
On Wed, 16 Sep 2009, Tomas Hlavaty wrote: Hi Henrik and TC, I just realized that there is an ambiguity here since I can't seem to accomplish a pair looking like this: (key . (1 2 3)), no matter how I try I get: (key (1 2 3)), if the Heh, I think the problem is quite obvious when looking to the list as what it really is: a chain of cons. (key (1 2 3)) - (key . ((1 . (2 . (3 . NIL) that's equivalent to: (key . (1 2 3)) = (key (1 2 3)) Brain farts happen... (key . ((1 2 3))) = (key (1 2 3)) -- This is what I tried to say. well, picolisp says that: : '(key . (1 2 3)) - (key 1 2 3) : I know, I knew this since I sent that email, but since it was only to show _why_ the (Sym . list) was not going to work, it wasn't worth it to send another email fixing this. In any case I can't think of a situation where I would have a string with quotes in it. That seems to me like a serious flaw:-( Regards, Tomas -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: The 64-bit version is complete
On Mon, 7 Sep 2009, Alexander Burger wrote: On Sun, Sep 06, 2009 at 04:28:04PM -0300, TC wrote: I don't see it in the repo, maybe you forgot to _push_? Ah, sorry, then we have a misunderstanding. As far as I remember, we agreed that I will not push ongoing development code (i.e. the 64-bit stuff), and we wait until 3.0 is finished. Sorry, I misunderstood the line: function in the 64-bit version (it was 'commit', btw)! Now the 64-bit I thought the it was 'commit', btw meant you put the changes in the repo. That's all. :) I suggest that we wait till the beginning of October, then set up a fresh initial repository (I considered the current one as experimental) I agree. which will contain the whole system including the 32-bit stuff (but not the 64-bit stuff, as this is still too much in a flow). I'll continue with providing the base system releases, if possible in three-month-cycles as before, and everybody is free to add and maintain extensions in the hg repo. Gd :) Even better I would find if I would not have to care about the hg repo at all, and some of our specialists (tc.rucho, hsarvell, ..) could take the responsibility of adding/updating base system changes to the repo. It's fine by me. No problem. This means that only the responsibility of the base system stays with me, and I would have to implement custom change requests manually as before, but this would save me a lot of time in total. The responsibility for custom extensions and modifications in the repo stays with the individual who initiated them. Is this ok? It's reasonable and fair. I agree. Although it would be nice if core changes were kept in the repository, everyone should be free to work the way they prefer. I'm eager to see what pL will turn into :D (of course, I'll help (how I can and in my way though :P )) -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: From Pico to JSON in the client
On Fri, 4 Sep 2009, Henrik Sarvell wrote:
I just realized that there is an ambiguity here since I can't seem to
accomplish a pair looking like this:
(key . (1 2 3)), no matter how I try I get: (key (1 2 3)), if the
Heh, I think the problem is quite obvious when looking to the list as what
it really is: a chain of cons.
(key (1 2 3)) - (key . ((1 . (2 . (3 . NIL)
that's equivalent to:
(key . (1 2 3)) = (key (1 2 3))
first one is really impossible then any JSON converter will stumble on
it since it's impossible to know if [key, [1, 2, 3]] or {key: [1,
2, 3]} is the desired result.
What if:
(key (1 2 3)) - [key, [1, 2, 3]]
(:key (1 2 3)) - {key: [1, 2, 3]}
(I suggest the ':' to be put at the beginning of the key-word for conventions'
sake.)
On Thu, Sep 3, 2009 at 11:20 PM, Henrik Sarvellhsarv...@gmail.com wrote:
First of all, to offload the server from having to build json all the tim=
e.
For me the real issue is not speed in the client, given that premise I
simply took a wild guess that building the json and then evaluating it
is a simpler road to take than actually building the composite objects
right away. For me it doesn't matter if the result is even ten times
slower as long as I can do as simple a solution as possible, people
sit on such powerful machines anyway.
Anyway, I've fixed things, incorporating Mateusz changes. However it
wouldn't work with recognizing single pairs/objects so quotes inside
keys are still a no no. This is hair splitting though, I don't even
know if they are legal in the keys. In any case I can't think of a
situation where I would have a string with quotes in it.
I've updated the article, looks like it's working, the string
evaluates OK and we can access values in the resulting object/array.
/Henrik
On Thu, Sep 3, 2009 at 7:55 PM, Tomas Hlavatyt...@logand.com wrote:
Hi Henrik,
That's exactly what I'm doing, ie stepping recursively, the regex is
just to determine which state to put the parser in. But yes, it looks
like I'm going to have to step through in order to determine type too
if no regex guru shows up :)
as Alex suggests, regular expressions in this context are overkill.
Instead, I would use a simple recursive parser (analog to the Lisp
reader), which can analyze the expression step by step in a more
flexible way.
Yes. You can simulate peek, char, skip etc. functions in javascript
closures and write a recursive parser. =A0I have done this in three
cases:
1) Parsing sexp: function parse(S) in http://ondoc.logand.com/ondoc.js
=A0 is not complete (dot notation is missing) and needs some
=A0 improvements based on the lesson learned from the postscript parser
=A0 bellow.
=A0 OnDoc http://logand.com/sw/ondoc/index.html uses sexp completely
=A0 for communication between client and server. =A0Ideally, I would lik=
e
=A0 to replace javascript by client-side picolisp (implemented in
=A0 javascript) completely. =A0I think it is feasible and could be
=A0 efficient enough. =A0Imagine having persistent symbols/objects
=A0 directly accesible in your client-side picolisp application;-)
2) Parsing PDFs in OnDoc: works surprisingly well fast in picolisp.
3) Parsing postscript: function PsParser() in
=A0 http://logand.com/sw/wps/wps.js
=A0 WPS http://logand.com/sw/wps/index.html proved to me that
=A0 implementing interpreters in javascript is reasonably efficient
=A0 although not great for coding things in a tight loop (which is
=A0 usually quite little code and could be implemented directly in
=A0 javascript, similarly to picolisp falling back to C).
I am not sure, why would you need to build json on the client side
this way unless you send it to some 3rd party. =A0Json as such is a data
transfer format and I guess I need the real objects on the client side
and not yet another representation of them.
Regards,
Tomas
--
UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=3dunsubscribe
--
UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
--
UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: How XML Threatens Big Data
On Mon, 24 Aug 2009, Henrik Sarvell wrote: I'm currently fetching data from a Java source which is giving me back XML (one of the world's biggest poker networks), it looks something like this: xml headerfieldname1;fieldname2/header datadata1;data2::data1;data2/data /xml Everyone who really has to send A LOT of data back and forth ends up doing something like the above ;-) No matter what, I still twitch when I see people reinventing the wheel the wrong way like with xml, json and stuff. S-exps are way more efficient and easier to parse than all that crap, and pre-date (If only it were predate...) them. Yet people keep messing with xml, html, json, etc, and when one brings s-exps to the discussion, they say lisp is dead, forget it or some bullshit like that, or just disregard the comment silently and keep doing things the way they have been doing them so far. Anyway, given the above it made me smile reading that article. It's annoying that good marketing can impose such bullshit on our industry, I mean we're supposed to be more rational than most people aren't we? /Henrik On Mon, Aug 24, 2009 at 10:47 AM, Randall Dowr...@randix.net wrote: Must reading for anyone designing data storage! How XML Threatens Big Data http://dataspora.com/blog/xml-and-big-data/ (and I will add, little data, too.) Anyone for WSDL? What a catastrophe. Flame bait: -- Java was invented (mainly marketed) by Sun in order to increase HW sales. Most of the big business where I have worked (banks, mobile telecoms) could do with less than 1/4th (1/10th??) of the HW they have today, if they used reasonable software. It is all Java, XML, Oracle, and SOAP. =A0It is very appropriate that Sun is being eaten (for dessert) by Oracle. Sun started by trying to change the world with unix but has fallen prey to the mass Java marketing that they started. (ok, I didn't get all of that out of the article above, but it is my opin= ion.) -- Flame off! Alex, I like picolisp and its data storage! -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=3dunsubscribe -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: Version control for PicoLisp
On Fri, 21 Aug 2009, Henrik Sarvell wrote: I think any kind of private server is overkill for a 250K source, my suggestion then is to go for Google Code. However, someone still needs to set it up. If TC wants to/have the time then I suggest he sets it up on Google code (he seems to be the best qualified here). I have no problem with that, but it will have to wait a bit since google code is undergoing some scheduled manteinance at the moment. With Pico on google code I could add my own stuff, such as JSON encoding/decoding, templating, general helper library and robust RSS XML parsing. This is all highly experimental and buggy stuff, that's why I've never bothered having Alex put it there manually (so much is changing in these things all the time). That sounds interesting :¬) Effective community coding.., this is what dvcs systems were conceived for ;¬) Every contribution would eventually mature enough to make it's way to the stable branch, and... we would have a wider range of tools, libs and a more versatile picolisp distribution overall. All of this keeping picolisp bloat free of course ;¬) /Henrik On Fri, Aug 21, 2009 at 11:26 AM, Alexander Burgera...@software-lab.de wro= te: On Fri, Aug 21, 2009 at 09:48:57AM +0200, Henrik Sarvell wrote: http://bitbucket.org/plans/. PicoLisp is such a small repository that we can go free on either BitBucket or GitHub. ... Then I randomly ended up at this comparison page: http://www.rockstarprogrammer.org/post/2008/apr/06/differences-between-m= ercurial-and-git/ In addition, we might want to consider other possibilities. - Jakob Eriksson comes to mind, he once reserved the domain =A0picolisp.org but we did not use it so far. Jakob? - Or Tomas Hlavaty who already started the PicoWiki on his logand.com. =A0Wouldn't it make sense to put these things together? - I could host it on 7fach.de, where the demo apps and this mailing =A0list are running. But if possible I'd like to avoid another task ;-) Cheers, - Alex -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=3dunsubscribe -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: Version control for PicoLisp (2nd wave)
That git-related article was old. Here are some links you may find solid enough: http://nubyonrails.com/articles/five-features-from-mercurial-that-would-make-git-suck-less http://blog.red-bean.com/sussman/?p=116 Sorry for the double reply, but bear with me please (: On Fri, 21 Aug 2009, Henrik Sarvell wrote: Hi all, there's been some discussion in various places, the IRC channel for instance to use some kins of version control system instead of having Alex laboriously, manually inserting changes. I just searched for a Mercurial version of GitHub and found http://bitbucket.org/plans/. PicoLisp is such a small repository that we can go free on either BitBucket or GitHub. Then I randomly ended up at this comparison page: http://www.rockstarprogrammer.org/post/2008/apr/06/differences-between-mercurial-and-git/ After reading that (which I recommend anyone who wants to chime in on this thread do) I realized that maybe Mercurial isn't the right way to go? It all depends on what we see happening in the future. I've never used Git (other than simply downloading code). If Alex will have the time to act as the guy who gets to decide what goes in and not, and wants superior control of that process then GitHub seems to be the way to go. If no one really will have that time and energy then maybe BitBucket is the way to go, I don't know, maybe GitHub will be a better choice either way. Maybe someone more knowledgeable could provide a more nuanced perspective as I'm not a power user of any VCS. /Henrik -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Locale minor fix
Hi guys, I'm new to picolisp (just knew about it yesterday) and it definitely got my curiosity. I was checking the locales and thougt ok, I'm gonna write one, but when I checked the testing version, I saw that the locales in question were already added, so I took a peek and couldn't avoid fixing some minor things. I've attached the patches. Have a good day.--- loc/es~ 2008-11-16 05:42:18.0 -0200 +++ loc/es 2009-08-19 15:41:25.0 -0300 @@ -8,7 +8,7 @@ Numeric input expected Se espera el ingreso de datos tipo numérico Symbolic type expected Se esperan datos del tipo simbólico String type expected Se esperan datos del tipo String -Type error Tipo de error +Type error Error de tipado Not unique No único Input required Se require ingreso de datos @@ -21,7 +21,7 @@ Show Mostrar Bad date format El formato de la fecha no es válido Bad time format El formato de la hora no es válido -Bad phone number format El formato del número telefónico no es válido +Bad phone number format El formato del número telefónico no es válido male varón female mujer New Nuevo @@ -33,9 +33,9 @@ Reset Vaciar/Limpiar New/Copy Nuevo/Copiar Restore Restaurar -Restore @1? ¿Restaura @1? +Restore @1? ¿Restaurar @1? Delete Borrar -Delete @1? ¿Borra @1? +Delete @1? ¿Borrar @1? Data not found No se encontraron datos # General --- loc/AR.l~ 2008-05-19 06:15:31.0 -0300 +++ loc/AR.l2009-08-19 15:29:12.0 -0300 @@ -3,5 +3,5 @@ *Sep3 . *CtryCode 54 *DateFmt '(@D . @M . @Y) - *DayFmt '(Lunes Martes Miercoles Jueves Viernes Sabado Domingo) + *DayFmt '(Lunes Martes Miércoles Jueves Viernes Sábado Domingo) *MonFmt '(Enero Febrero Marzo Abril Mayo Junio Julio Agosto Setiembre Octubre Noviembre Diciembre) )
Re: Locale minor fix
I couldn't agree more. Proposal++ :D On Thu, 20 Aug 2009, Henrik Sarvell wrote: Maybe we should but the mature 32bit version on Mercurial then everyone could submit to their hearts content and then Alex could very easily choose which stuff he wants to merge into each new release or something. This is starting to feel primitive, what do you think Alex? /Henrik 2009/8/20 TC tc.ru...@gmail.com: Hi guys, I'm new to picolisp (just knew about it yesterday) and it definitely got my curiosity. I was checking the locales and thougt ok, I'm gonna write one, but when I checked the testing version, I saw that the locales in question were already added, so I took a peek and couldn't avoid fixing some minor things. I've attached the patches. Have a good day. -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
app/loc/es
Here you go, this is the missing 'es locale.# 20aug09art # TC tc.ru...@gmail.com (@1 Positions) (@1 Posiciones) Address Dirección Can't print order No se puede imprimir la órden Change Cambiar City Ciudad Contact Contacto Continued on page @1 Continuado en la página @1 Country País Customer Cliente Customer/Supplier Cliente/Proveedor Customers/Suppliers Clientes/Proveedores Data Datos Date Fecha Dear Sir or Madam, Estimado/a Sr/a, Description Descripción eMail eMail Fax Fax Full Name Nombre Completo Greeting Saludos Home Inicio Incomplete customer address Dirección del cliente incompleta Install Instalar Inventory Inventario Item Artículo Items Artículos Login Name Nombre de usuario Memo Memo Mobile Celular/Móbil Name Nombre Name 2 Segundo nombre No customer No cliente No customer name Nombre de cliente indefinido No customer number Número de cliente indefinido No item description Descripción de artículo indefinida No item number Número de artículo no definido No order date Fecha de órden, indefinida No order number Número de órden indefinido No positions Posiciones indefinidas Number Número Order Órden Orders Órdenes Page @1 Página @1 PDF-Print Imprimir-PDF Phone Teléfono Picture Foto Position without item Posición sin artículo Position without price Posición sin precio Position without quantity Posición sin cantidad Price Precio Quantity Cantidad Report Reporte Role Administration Administración de roles Sales Ventas Salutation Saludo Salutations Saludos Sex Género Street Calle Supplier Proveedor System Sistema Total Total Uninstall Desinstalar Uninstall Picture? Desinstalar foto? User Administration Administración de usuarios Zip Código Postal
Subscribe
Hello TC tc.ru...@gmail.com :-) You are now subscribed -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
