armedbear-devel

armedbear-devel@common-lisp.net

1 participants
1200 discussions

Re: [armedbear-devel] run-program :environment nil
by Ville Voutilainen 29 Mar '12

29 Mar '12

Forwarding my reply to the list too. :) On 29 March 2012 16:55, Ville Voutilainen <ville.voutilainen(a)gmail.com> wrote: > On 29 March 2012 16:41, Rudi Schlatte <rudi(a)ifi.uio.no> wrote: >> Ville Voutilainen <ville.voutilainen(a)gmail.com> writes: >>> Here's a tentative patch. I opted for a new keyword argument, since >>> the new function approach would've led to duplication or to a macro >>> that has the new argument anyway. Untested so far, so this is for >>> general review. Also lacking the docstring changes. >> Here's my version, using your getenv and process-builder changes. I >> get by with only the :environment key, see the docstring for an example >> on how to overwrite PATH and keep the rest. Lightly tested. > > Looks reasonable. Some questions though: > >> -(defun run-program (program args &key environment (wait t)) >> +(defun run-program (program args &key (environment nil environment-p) (wait t)) > > Ah, yes, this works too, no need for a separate clear-env. But, does > this change the > semantics? Our previous code did an environment-merge if an > environment is supplied. > This one will clear and insert, and requires using getenv-all if you > want to replace > only some parts. I don't want to do such a semantics change. By > avoiding the semantics > change, I don't need to worry about breaking asdf. > > For that point, I'm still biased towards the clear-env keyword arg > approach. In that > approach, getenv-all is just an utility function that you can use if > you want to do > weird-complex environment processing, but possibly the most common use cases are > still "replace a couple of values by providing an environment without > clearing" and > "run in a very restricted environment with only a handful of > variables", neither of > which requires the use of getenv-all. > > Comments?

1 0

Re: [armedbear-devel] run-program :environment nil
by Rudi Schlatte 29 Mar '12

29 Mar '12

[Originally sent to Ville only because of a disagreement between Gnus and me]

1 0

[armedbear-devel] run-program :environment nil
by Pascal J. Bourguignon 29 Mar '12

29 Mar '12

(lisp-implementation-version) --> "1.0.1" The documentation of extensions:run-program is misleading: :environment An alist of STRINGs (name . value) describing the new environment. The default is to copy the environment of the current process. The alist doesn't describe the NEW environment, it is only MERGED into the current environment. Now of course, I consider the current behavior to be a bug: (text-stream-contents (extensions:process-output (extensions:run-program "env" '() :wait t :environment 'nil))) --> ("NNTPSERVER=news.individual.net" "ESHELL=/bin/bash" …) I would expect: (text-stream-contents (extensions:process-output (extensions:run-program "env" '() :wait t :environment 'nil))) --> () and: (text-stream-contents (extensions:process-output (extensions:run-program "env" '() :wait t :environment '(("LC_CTYPE" . "C"))))) --> ("LC_CTYPE=C")) Which would match what the documentation says. Also, in a shell environment, an empty variable is not the same as an inexistant variable, so I cannot just loop over all the existing variables to set them to an empty string. I see no SYSTEM::%PROCESS-BUILDER-ENV-REM function… -- __Pascal Bourguignon__ http://www.informatimago.com/ A bad day in () is better than a good day in {}.

4 8

[armedbear-devel] ABCL on jdk-1.7.0_03
by Mark Evenson 21 Mar '12

21 Mar '12

I've just run abcl-1.1.0-dev the ANSI-COMPILED tests on jdk-1.7.0_03 with reasonable looking results of 31 failures, which is roughly the same number as those run with jdk-1.6.0_31 (some of the tests use randomly generated data so they sometimes either fail or succeed). Previously, I think that we weren't even completing the ANSI-COMPILED test suite due to issues in the character set encoding, so I think we should now more fully endorse running ABCL on Java7.

1 0

[armedbear-devel] compiled errors: debug.assertTrue()
by scarbonell＠ono.com 06 Mar '12

06 Mar '12

Hi, When I try to compile the mcs-core.cl file (attached) with java abcl, I get this error: Failed to get InputStream for 'jar:file:D:/otro/kernel/modules/fmcs.bin!/mcs_core_4.cls'ABCL Debug.assertTrue() assertion failed!java.lang.Error: ABCL Debug.assertTrue() assertion failed! Why is this happening? How can I resolved it? Thanks

3 3

[armedbear-devel] compiling lisp files outside Java and calling it after with abcl
by scarbonell＠ono.com 02 Mar '12

02 Mar '12

Hi,I'm trying to compile a lisp application and I get a lot of errors with java abcl. I thought that if I try to compile this lisp files outside of abcl with other systems, perhaps, I could then call this compiled functions lisp files from ABCL (look like a jar file of lisp compiled files). Is this possible?How can I compiled this files outside ABCL? Some examples?Thanks

5 10

[armedbear-devel] Upcoming abcl-1.1 branch
by Mark Evenson 25 Feb '12

25 Feb '12

On [#abcl]() yesterday, ehu and easye discussed how it would be a good idea to start packing up for shipping abcl-1.1 out the door. [#abcl]: http://webchat.freenode.net/?randomnick=1&channels=abcl&prompt=1&uio=d4 Out of our brief discussion, we'd like to branch the trunk in about a week, stabilize with testing, and then release abcl-1.1.0 on 14-FEB-2012. So, unless there are objections, we'd like to start by asking everyone who was thinking of patching something, to think about getting some time in the next week to get something done. All potential contributions are welcome. If you were going to document something, now's the time! [Rudi added real BibTex-based markup to the Manual][1], so even something as trivial as fixing the references would be appreciated. [1]: http://code.google.com/p/abcl-dynamic-install/source/detail?r=5c7faeeb35408… yers in CONS, Mark -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

2 2

[armedbear-devel] Patch for ABCL to dynamically load CFFI JNA requirement
by Mark Evenson 24 Feb '12

24 Feb '12

Please consider the referenced patch for inclusion in cffi-0.10.7. Comments towards improvments solicited. Improvements to ABCL CFFI implementation: o autoload the 'jna.jar' dependency if possible (requires abcl-1.1.0-dev) o initial implementation of callbacks Needs ABCL specific tests, but I can load CL+SSL with this patch. [1]: http://slack.net/~evenson/abcl/cffi/abcl-cffi-20120224a.diff Cheers, easyE -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

1 0

[armedbear-devel] 김영태님이 Abcl님을 Facebook으로 초대하셨습니다
by Young Tae Kim 05 Feb '12

05 Feb '12

안녕하세요, Abcl님! 내 사진, 동영상, 이벤트를 게시할 수 있는 Facebook 프로필을 만들었습니다. 귀하가 저의 프로필을 볼 수 있도록 친구로 추가하고 싶습니다. 그러려면 먼저 귀하가 Facebook에 가입해야 합니다! 회원으로 가입하면 귀하도 프로필을 만들 수 있습니다. 고맙습니다! Young Tae Facebook에 가입하려면 아래 링크를 클릭하세요. http://www.facebook.com/p.php?i=100003305725765&k=AQCtufVGAiIaS35gg9kHoIHhT… 이미 계정을 갖고 계신가요? 계정에 이 이메일 주소를 추가하세요. http://www.facebook.com/n/?merge_accounts.php&e=armedbear-devel%40common-li… ======================================= 메시지가 armedbear-devel(a)common-lisp.xn--net()-7s4ut57e 전송되었습니다. 앞으로 이러한 이메일을 그만 받으려면 아래의 링크를 눌러서 수신을 거부해 주세요. http://www.facebook.com/o.php?k=a23045&u=100003558065807&mid=5989382G5af3e4… Facebook, Inc. Attention: Department 415 P.O Box 10005 Palo Alto CA 94303

1 0

[armedbear-devel] Patch that fixes ticket #187 (Stack Overflow for Worst-case Vector Sort)
by Jorge Tavares 05 Feb '12

05 Feb '12

Hi, I'm sending a patch that solves the issue reported in ticket #187. The quicksort function picks the pivot by selecting a midpoint and also sorts the smaller partition first. These are enough to avoid the stack overflow problem as reported. I've performed some tests and it looks it is correct. Below I include a sample session, including the test case in the ticket: idesk:abcl jast$ ./abcl Armed Bear Common Lisp 1.1.0-dev-svn-13848M Java 1.6.0_29 Apple Inc. Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.307 seconds. Startup completed in 0.945 seconds. Loading /Users/jast/.abclrc completed in 4.528 seconds. Type ":help" for a list of available commands. CL-USER(1): (ql:quickload "alexandria") To load "alexandria": Load 1 ASDF system: alexandria ; Loading "alexandria" ("alexandria") CL-USER(2): (defparameter *sorted* (make-array 1000000 :initial-contents (alexandria:iota 1000000))) *SORTED* CL-USER(3): (defparameter *numbers* (alexandria:shuffle (copy-seq *sorted*))) *NUMBERS* CL-USER(4): (equalp *sorted* *numbers*) NIL CL-USER(5): (time (progn (setf *numbers* (sort *numbers* #'<)) nil)) 2.157 seconds real time 3 cons cells NIL CL-USER(6): (equalp *sorted* *numbers*) T CL-USER(7): (let ((a (map-into (make-array 10000) (let ((x 0)) (lambda () (incf x)))))) (sort a #'<) nil) NIL CL-USER(8): (time (progn (setf *numbers* (sort *numbers* #'<)) nil)) 1.074 seconds real time 3 cons cells NIL CL-USER(9): With these changes, sort seems to be a little faster (for vectors) although I was not worried with optimizations. In ABCL 1.0.1, in my machine, sorting 1000000 random integers takes around 10s on average while now it takes 2s. However, I must point out I didn't do any serious and proper benchmarking, just some runs. I will be happy to answer any questions if necessary. Cheers, Jorge Tavares -- http://jorgetavares.com

2 2

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

armedbear-devel