Re: bug in (log)

[Stas Boukarev]

This is permitted by
http://www.lispworks.com/documentation/HyperSpec/Body/12_acc.htm

On Sun, Jul 3, 2022 at 12:10 AM James Cloos  wrote:
>
> (gitlab is uusable; i have to report here.)
>
> ecl 21.2.1 gives:
>
> > (log 1/6319748715279270675921934218987893281199411530039296)
>
> Debugger received error of type: DIVISION-BY-ZERO
> #
> Error flushed.
>
> whereas other cl's (i testyed sbcl and ccl) give results like:
>
> ? (log 1/6319748715279270675921934218987893281199411530039296)
> -119.27552
>
> I tested on amd64 (gentoo) and arm64 (debian and netbsd) with identical
> results.  i did not have a musl box or other bsd to test on.
>
> run with --no-trap-fpe, the result is #.
>
> another example is:
>
> (truncate (log 1/6319748715279270675921934218987893281199418867))
>
> Debugger received error of type: ARITHMETIC-ERROR
> #
>
> whereas this works:
>
> (truncate (log 1/631974871527927067592193421898789328119941867))
>
> -103
> -0.27893066
>
> which of course suggests that the issue is c's long double's precision.
>
> it looks like ecl could use an mpq log function;
> https://github.com/linas/anant might work.
>
> -JimC
> --
> James Cloos  OpenPGP: 0x997A9F17ED7DAEA6
>

Re: why does ASDF ask to please only define system/test?

[Stas Boukarev]

I specifically don't update cl-ppcre.asd, so that these messages annoy as
many people as possible and they complain to ASDF. cl-ppcre/test works
perfectly fine, nobody calls find-system on it, it's only ever used
via (asdf:test-system :cl-ppcre), which still works.

ASDF is an entrenched monopoly, there's no competition and you can't just
choose some other system to use. So it can change its behavior with every
release and all the users can do is just to suck it up.

On Tue, Dec 11, 2018 at 10:09 PM Mark H. David  wrote:

> It seems that any system Y associated with a name X must have its name be
> of the form X/Y.  For example, when you build "cl-ppcre", you get this
> warning:
>
> Please only define "cl-ppcre" and secondary systems with a name starting
> with "cl-ppcre/" (e.g. "cl-ppcre/test") in that file.
>
> I've seen this complaint for quite a few systems already. What's the need
> for this, and is it really worth nagging users of all these systems that
> have existed in many cases for years and have worked perfectly well without
> following the new convention? What great functionality are we getting for
> this?
>
> Thanks,
> -Mark
>
>

Re: [cfarm-users] Looking for the latest GCC for PowerPC

[Stas Boukarev via cfarm-users]

Can't you just build one locally?

On Thu, Dec 6, 2018 at 10:37 AM Jeffrey Walton via cfarm-users <
cfarm-users@lists.tetaneutral.net> wrote:

> Hi Everyone,
>
> I'm looking for the latest GCC for PowerPC. I think I need something
> from this week or last week.
>
> GCC135 has "gcc version 8.2.1 20180813" but I am looking for something
> newer. The other PowerPCs seem to be older, like GCC 6.2 or 8.2.0.
>
> Does anyone know where to find the latest GCC?
>
> Jeff
> ___
> cfarm-users mailing list
> cfarm-users@lists.tetaneutral.net
> https://lists.tetaneutral.net/listinfo/cfarm-users
>
___
cfarm-users mailing list
cfarm-users@lists.tetaneutral.net
https://lists.tetaneutral.net/listinfo/cfarm-users

Re: [cfarm-users] OT: Spectre and Meltdown cpu bugs

[Stas Boukarev via cfarm-users]

Well, don’t do that? You already have to trust the farm admins not to do
that.
I wouldn’t want a compiler farm to slow down because somebody is doing
online banking on it.

On Sat, 6 Jan 2018 at 21:07 Paul Hargrove <phhargr...@lbl.gov> wrote:

> We all login to the CFarm system using ssh keys.
> IF you use agent forwarding AND a key trusted elsewhere, you could be a
> target of ssh-agent hijacking.
>
> -Paul
>
> On Sat, Jan 6, 2018 at 2:30 AM, Stas Boukarev via cfarm-users <
> cfarm-users@lists.tetaneutral.net> wrote:
>
>> Do people really process sensitive data on the compiler farm?
>>
>>
>> On Sat, Jan 6, 2018 at 5:21 AM Jeffrey Walton via cfarm-users <
>> cfarm-users@lists.tetaneutral.net> wrote:
>>
>>> Hi Everyone,
>>>
>>> It looks like PoCs are starting to be released for the CPU bugs. Or
>>> there's a PoC in the wild for ARM processors. The farm may want to
>>> accelerate deployment of the fixes if it has not done so.
>>>
>>> Early reports:
>>> * https://amp.reddit.com/r/sysadmin/comments/7nl8r0/intel_bug_incoming/
>>> * https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/
>>>
>>> Latest news:
>>> *
>>> https://www.theverge.com/2018/1/4/16848976/how-to-protect-windows-pc-meltdown-security-flaw
>>>
>>> Jeff
>>> ___
>>> cfarm-users mailing list
>>> cfarm-users@lists.tetaneutral.net
>>> https://lists.tetaneutral.net/listinfo/cfarm-users
>>>
>>
>> ___
>> cfarm-users mailing list
>> cfarm-users@lists.tetaneutral.net
>> https://lists.tetaneutral.net/listinfo/cfarm-users
>>
>>
>
>
> --
> Paul H. Hargrove <phhargr...@lbl.gov>
> Computer Languages & Systems Software (CLaSS) Group
> Computer Science Department
> Lawrence Berkeley National Laboratory
>
___
cfarm-users mailing list
cfarm-users@lists.tetaneutral.net
https://lists.tetaneutral.net/listinfo/cfarm-users

Re: [cfarm-users] OT: Spectre and Meltdown cpu bugs

[Stas Boukarev via cfarm-users]

Why would  I care. They are already on the server, can already do these
things.

On Sat, 6 Jan 2018 at 19:42 Bart Van Assche <bvanass...@acm.org> wrote:

> On 01/06/18 02:30, Stas Boukarev via cfarm-users wrote:
> > Do people really process sensitive data on the compiler farm?
>
> Would you like it if a security bug would allow someone to log in under
> your account and abuse your account to perform e.g. a DOS attack or to
> attempt to hack another server?
>
> Bart.
>
___
cfarm-users mailing list
cfarm-users@lists.tetaneutral.net
https://lists.tetaneutral.net/listinfo/cfarm-users

Re: [cfarm-users] OT: Spectre and Meltdown cpu bugs

[Stas Boukarev via cfarm-users]

Do people really process sensitive data on the compiler farm?

On Sat, Jan 6, 2018 at 5:21 AM Jeffrey Walton via cfarm-users <
cfarm-users@lists.tetaneutral.net> wrote:

> Hi Everyone,
>
> It looks like PoCs are starting to be released for the CPU bugs. Or
> there's a PoC in the wild for ARM processors. The farm may want to
> accelerate deployment of the fixes if it has not done so.
>
> Early reports:
> * https://amp.reddit.com/r/sysadmin/comments/7nl8r0/intel_bug_incoming/
> * https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/
>
> Latest news:
> *
> https://www.theverge.com/2018/1/4/16848976/how-to-protect-windows-pc-meltdown-security-flaw
>
> Jeff
> ___
> cfarm-users mailing list
> cfarm-users@lists.tetaneutral.net
> https://lists.tetaneutral.net/listinfo/cfarm-users
>
___
cfarm-users mailing list
cfarm-users@lists.tetaneutral.net
https://lists.tetaneutral.net/listinfo/cfarm-users

Re: Warning: Computing just-done stamp in plan NIL for action

[Stas Boukarev]

The systems working on older asdf versions is wrong?

On Wed, Oct 18, 2017 at 8:48 PM Faré <fah...@gmail.com> wrote:

> On Wed, Oct 18, 2017 at 12:58 PM, Stas Boukarev <stass...@gmail.com>
> wrote:
> > ASDF keeps inventing good reasons all the time...
> >
> Indeed , "inventing" in the original sense of the term: finding a
> preexisting thing that no one suspected existed, but that was there of
> all times. See my post about a previous occurrence of the pattern with
> ASDF 3.0: https://fare.livejournal.com/176185.html — ASDF 3.3 was also
> fixing a bug, doing it right, and discovering that some things had
> been wrong all along.
>
> —♯ƒ • François-René ÐVB Rideau •Reflection•
> http://fare.tunes.org
> A child of five would understand this. Send someone to fetch a child of
> five.
> — Groucho Marx
>

Re: Warning: Computing just-done stamp in plan NIL for action

[Stas Boukarev]

ASDF keeps inventing good reasons all the time...

On Wed, Oct 18, 2017 at 7:43 PM Faré <fah...@gmail.com> wrote:

> Oh, is it a case where you're insisting on using a secondary system
> name that doesn't follow the convention B/A when the primary system is
> B ? That might explain it. There is also a warning against such a
> thing, and for good reason.
>
> —♯ƒ • François-René ÐVB Rideau •Reflection•
> http://fare.tunes.org
> Doing well is the result of doing good. That's what capitalism is all
> about.
> — Ralph Waldo Emerson (1803–1882)
>
>
> On Wed, Oct 18, 2017 at 12:15 PM, Stas Boukarev <stass...@gmail.com>
> wrote:
> > cat b.asd
> > (defsystem A)
> >
> > (defsystem B
> >   :depends-on (A))
> >
> > (asdf:load-system 'b) is enough to trigger it.
> >
> > On Wed, Oct 18, 2017 at 6:51 PM Faré <fah...@gmail.com> wrote:
> >>
> >> See section 4 of the ASDF 3.3 paper at ILC 2017 for a quick overview:
> >> https://github.com/fare/asdf2017
> >>
> >> To support proper phase separation, ASDF has a new operation,
> >> define-op, that tracks the dependencies of loading a .asd file (i.e.
> >> other systems you operate on, e.g., via load-system or
> >> defsystem-depends-on, etc.)
> >>
> >> I don't know exactly what is your system A and how you use it, but
> >> apparently it's unhappy about depending on the primary system for
> >> define-op yet being earlier in the .asd file, so the other system
> >> hasn't been defined yet.
> >>
> >> Maybe ASDF should refrain from registering a dependency here between
> >> sibling systems. Or not. It was quite subtle to debug about a year
> >> ago, and it fell out of my working cache.
> >>
> >> Is there anything special you do between A and B except a :depends-on ?
> >>
> >> —♯ƒ • François-René ÐVB Rideau •Reflection•
> >> http://fare.tunes.org
> >> You think war is economically beneficial? Then why share those benefits
> >> with
> >> dirty foreigners? Let's have a civil war — A war we're sure to win!
> >>
> >>
> >> On Wed, Oct 18, 2017 at 11:34 AM, Stas Boukarev <stass...@gmail.com>
> >> wrote:
> >> > It’s a regular depends-on, but why did it work before without
> problems?
> >> >
> >> > On Wed, 18 Oct 2017 at 18:32 Faré <fah...@gmail.com> wrote:
> >> >>
> >> >> On Wed, Oct 18, 2017 at 11:25 AM, Stas Boukarev <stass...@gmail.com>
> >> >> wrote:
> >> >> > B is primary, but A has to be loaded before it. It precedes B, and
> B
> >> >> > depends
> >> >> > on it.
> >> >> >
> >> >> If it's a regular :depends-on, then B should be able to appear before
> >> >> A, and that should actually work better.
> >> >>
> >> >> If it's a :defsystem-depends-on, it used to be that A must be before
> >> >> B, but the new situation is that they have to be in separate files
> for
> >> >> define-op to work at all.
> >> >>
> >> >> —♯ƒ • François-René ÐVB Rideau •Reflection•
> >> >> http://fare.tunes.org
> >> >> For ultimately, the most visible trait of a just man is to have no
> >> >> desire
> >> >> at all to rule others, and only want to rule himself. This decides
> >> >> everything. In other words, the worst people will rule. — Alain
> >> >>
> >> >>
> >> >>
> >> >> > On Wed, Oct 18, 2017 at 6:23 PM Faré <fah...@gmail.com> wrote:
> >> >> >>
> >> >> >> On Wed, Oct 18, 2017 at 11:13 AM, Stas Boukarev <
> stass...@gmail.com>
> >> >> >> wrote:
> >> >> >> > Looks like this happens because I have two systems in B.asd, A
> and
> >> >> >> > B,
> >> >> >> > and B
> >> >> >> > depends on A.
> >> >> >> Maybe changing the order of the two systems will help.
> >> >> >> Which is primary? Which depends on the other?
> >> >> >>
> >> >> >> —♯ƒ • François-René ÐVB Rideau •Reflection•
> >> >> >> http://fare.tunes.org
> >> >> >> All honest people are welcome to come and live here.
> >> >> >> All dishonest people are welcome to come and die here.
> >> >> >> — Libertarian Open-Borders, Open-Skulls Policy
>

Re: Warning: Computing just-done stamp in plan NIL for action

[Stas Boukarev]

No clear-system in sight, everything is declarative.

On Wed, Oct 18, 2017 at 4:42 PM Faré  wrote:

> On Wed, Oct 18, 2017 at 9:25 AM, Chream iz  wrote:
> > Hi, I am also getting this error when trying to run (asdf:test-system
> ).
> > It is also not finding the test-files but that might be an but in the
> prove
> > package?
> >
> >
> >   :defsystem-depends-on (:prove-asdf)
> >   :perform (test-op :after (op c)
> > (funcall (intern #.(string :run-test-system)
> > :prove-asdf) c)
> > (asdf:clear-system c)))
> >
> There is your culprit: clear-system should NEVER be called within
> perform. It's removing the rug under ASDF as it's running -- very BAD,
> especially if there are many build phases. Unhappily, prove and other
> prove-based system skeletons (e.g. from caveman) have made this
> pattern popular. I sent patches to prove & al. at least six months
> ago, and wrote about this anti-pattern in my "best_practices"
> document, but I suppose the message didn't go around yet. Maybe I
> should make it an error for clear-system to be called from within an
> active asdf-session?
>
> Stas, if you also use clear-system this way, you also lose for that reason.
>
> —♯ƒ • François-René ÐVB Rideau •Reflection•
> http://fare.tunes.org
> Young man, in mathematics you don't understand things,
> you just get used to them. — John von Neumann (1903-1957)
>
>

Re: Warning: Computing just-done stamp in plan NIL for action

[Stas Boukarev]

It's a work file, can't publish it. But it's just a defsystem with
depends-on and components.

On Wed, Oct 18, 2017 at 2:46 PM Faré <fah...@gmail.com> wrote:

> It's hard to tell without seeing the .asd file. The message says that
> you completed the load-op of the system, but somehow you never did the
> define-op of the system (the new action that tracks the loading of
> .asd files so that defsystem-depends-on can be properly staged).
>
> Can you tell us more about the "non-complicated" features that you
> use? Do you follow the "best practices" document?
> https://github.com/fare/asdf/blob/master/doc/best_practices.md
>
> —♯ƒ • François-René ÐVB Rideau •Reflection•
> http://fare.tunes.org
> Don't forget your daily prayer to Baah-kup,
> the God of data storage and recovery!
>
>
>
> On Wed, Oct 18, 2017 at 7:35 AM, Stas Boukarev <stass...@gmail.com> wrote:
> > More new warnings from ASDF 3.3, this time I have no idea what it means.
> >
> > WARNING:
> >Computing just-done stamp in plan NIL for action
> > (ASDF/LISP-ACTION:LOAD-OP
> >  "system"), but
> > dependency (ASDF/FIND-SYSTEM:DEFINE-OP
> >
> > "system") wasn't done yet!
> >
> > The .asd file is not public, but it looks perfectly normal without using
> any
> > complicated features.
>

Warning: Computing just-done stamp in plan NIL for action

[Stas Boukarev]

More new warnings from ASDF 3.3, this time I have no idea what it means.

WARNING:
   Computing just-done stamp in plan NIL for action
(ASDF/LISP-ACTION:LOAD-OP
 "system"), but
dependency (ASDF/FIND-SYSTEM:DEFINE-OP

"system") wasn't done yet!

The .asd file is not public, but it looks perfectly normal without using
any complicated features.

Re: WARNING: System definition file ...

[Stas Boukarev]

Yes, SBCL has a deprecation process that goes through several stages which
span several years. QUIT signals a style-warning, not warning, and is
unlikely to ever signal a warning and will never go away.

If you're willing to fix all the affected systems just go through
quicklisp, it'll have plenty. But maybe that should be done before
introducing new warnings.

On Thu, Oct 12, 2017 at 2:05 PM Faré <fah...@gmail.com> wrote:

> On Thu, Oct 12, 2017 at 6:00 AM, Stas Boukarev <stass...@gmail.com> wrote:
> > I get 12 warnings with "System definition file  contains definition for
> > system . Please only define and secondary systems with a name starting
> with
> > in that file." while loading a single project.
> >
> These are valid warnings, and those systems must be fixed. Can you
> give me a list of the affected systems, so I may send patches
> upstream?
>
> Background: Secondary systems (systems loaded in a .asd file beside
> the "primary" system that the .asd file is named after) that do not
> follow the / convention can't be found by name by ASDF before the .asd
> file is loaded; they can clash with other systems and then cause
> "interesting" behavior. They were an abuse that kind of worked but not
> really from the bad old ASDF 1 days. ASDF 3 fully supports secondary
> systems, but requires them to start with a prefix of foo/ where foo is
> the primary system name (that the .asd file is named after). The old
> behavior is still supported at this time, but we started issuing
> warnings this year, together with other deprecation warnings.
>
> > How do I disable these warnings? If we are to update ASDF in SBCL I want
> to
> > make the asdf.lisp version bundled with SBCL to have them disabled by
> > default.
> >
> The best way to disable to warnings is to fix the 12 affected libraries.
>
> If you modify ASDF to remove that message, please change all
> occurrences of "3.3.0" to "3.3.0.0.1" in the sources, too, to indicate
> one local change.
>
> > And if some future version of ASDF stops loading any of the 12 libraries,
> > then I just won't update SBCL to that ASDF version.
> >
> ASDF won't stop supporting that feature for at least the next 2 years.
> Those 12 libraries will have that much time to be fixed. If the last
> maintainers have quit, the libraries will have to be taken over by
> e.g. sharplispers some time before then.
>
> Experience shows that 2 years is about the time it takes for some
> change to "fully" propagate through the Common Lisp community (e.g.
> for a new version of ASDF to be used by all implementations). It is
> not an unreasonable target for backward compatibility of ASDF. I see
> no good reason to keep 15 or 26 year old bugs around indefinitely.
>
> SBCL does introduce new warnings at times, that sometimes affect tens
> of existing systems (e.g. the quit / exit renaming). I see no
> principled reason for SBCL to shy away from legitimate warnings from
> ASDF. How long did SBCL maintain backward compatibility with the old
> calling convention?
>
> PS: I wrote a function
> ql-test:find-misnamed-secondary-asdf-systems-in-quicklisp in my system
> ql-test https://gitlab.common-lisp.net/frideau/ql-test and it finds
> 330 suspect defsystem entries in quicklisp. Some are templates that
> can be ignored (and probably filtered out of this function), but most
> are legitimate issues that must be fixed in the next two years.
>
> —♯ƒ • François-René ÐVB Rideau •Reflection•
> http://fare.tunes.org
> If debugging is the process of removing bugs,
> then programming must be the process of putting them in.
> — Dijkstra
>

Re: WARNING: System definition file ...

[Stas Boukarev]

I get 12 warnings with "System definition file  contains definition for
system . Please only define and secondary systems with a name starting with
in that file." while loading a single project.

How do I disable these warnings? If we are to update ASDF in SBCL I want to
make the asdf.lisp version bundled with SBCL to have them disabled by
default.

And if some future version of ASDF stops loading any of the 12 libraries,
then I just won't update SBCL to that ASDF version.

On Thu, Oct 12, 2017 at 5:22 AM Faré <fah...@gmail.com> wrote:

> On Wed, Oct 11, 2017 at 9:14 PM, Stas Boukarev <stass...@gmail.com> wrote:
> > 3.3.0 issues a barrage of new warnings about something it has decided is
> > uncouth now.
> >
> On what systems is it issuing warnings? Any free software that we can
> patch?
>
> Without specific warnings coming from specific libraries, it's hard to
> tell what can be fixed, what cannot, what is an actual problem with
> the code you're using, what is possibly a problem about ASDF itself,
> etc.
>
> Odds are, the something had been decided as uncouth long ago, and ASDF
> just lacked the means to warn you about it.
>
> > I really have no wish to stare at these warnings coming from third party
> > libraries, especially since they're never going to be fixed.
> > Is the old behavior posing problems? Is the old behavior going away soon?
> >
> Yes, some old behavior is posing problem and has for years. Sometimes
> the old behavior has already gone away and/or is precariously emulated
> in slightly incompatible ways using the newer better interface.
> Sometimes we really want to get away from a really bad interface that
> has been deprecated for years (e.g. run-shell-command, which is a
> security liability in addition to been challenged with usability).
> Sometimes a recent refactoring made some operation non-sensical (e.g.
> operation-on-warnings) and/or not so useful (e.g. require-system), or
> a really bad interface to the system (system-registered-p).
>
> Depending on the interfaces, the old behavior may go away within two
> year, especially where supporting it is problematic and/or the
> interface is bogus and misleading and not properly doing what it was
> once advertised to be used for. Well, whoever is maintainer then will
> probably do something conservative that preserves compatibility (with
> some kind of warning) wherever it isn't an encouragement to writing
> nonsensical code.
>
> > This is why I don't update ASDF, I don't want to change anything in my
> code
> > because of a new version.
>
> Last I heard, janderson was using his own slightly forked ASDF 1, and
> some russians had forked ASDF 2.
>
> On the other hand, some programs depend on a recent ASDF, such as
> IOlib or CFFI, or scripts that depend on a fixes run-program or on its
> younger sibling launch-program, especially so on SBCL/Windows.
>
> There is no pleasing everyone, but there's going forward. SBCL also
> sometimes deprecates some old interfaces, and issues warnings to those
> who use them.
>
> —♯ƒ • François-René ÐVB Rideau •Reflection•
> http://fare.tunes.org
> Every four seconds a woman has a baby.
> Our problem is to find this woman and stop her.
>

WARNING: System definition file ...

[Stas Boukarev]

3.3.0 issues a barrage of new warnings about something it has decided is
uncouth now.
I really have no wish to stare at these warnings coming from third party
libraries, especially since they're never going to be fixed.
Is the old behavior posing problems? Is the old behavior going away soon?

This is why I don't update ASDF, I don't want to change anything in my code
because of a new version.

[Bug 1576871] Re: runtime config for x86 linux adds incorrect gcc -nopie flag

[Stas Boukarev]

** Changed in: sbcl
   Status: New => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1576871

Title:
  runtime config for x86 linux adds incorrect gcc -nopie flag

To manage notifications about this bug go to:
https://bugs.launchpad.net/sbcl/+bug/1576871/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Space wasted by FORMAT directive tables.

[Stas Boukarev]

I recently discovered that ECL creates very large tables for FORMAT directives:
https://gitlab.com/embeddable-common-lisp/ecl/commit/0c9e67345c364b3d41acca899d80a5c0c35152a6
this applies to MKCL as well.

-- 
With best regards, Stas.

[Marble-devel] [Differential] [Updated, 22 lines] D2152: Scale pixmap cache of MarbleGraphicsItem

[stassats (Stas Boukarev)]

stassats updated this revision to Diff 5131.
stassats added a comment.


  Add the rounding error pixel after the size is scaled.

REPOSITORY
  rMARBLE Marble

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D2152?vs=5130=5131

REVISION DETAIL
  https://phabricator.kde.org/D2152

AFFECTED FILES
  src/lib/marble/graphicsview/MarbleGraphicsItem.cpp

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: stassats, #marble, nienhueser, rahn
Cc: marble-devel
___
Marble-devel mailing list
Marble-devel@kde.org
https://mail.kde.org/mailman/listinfo/marble-devel

[Marble-devel] [Differential] [Updated, 22 lines] D2152: Scale pixmap cache of MarbleGraphicsItem

[stassats (Stas Boukarev)]

stassats updated this revision to Diff 5130.
stassats added a comment.


  Compare the scale when looking up cached pixmaps.

REPOSITORY
  rMARBLE Marble

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D2152?vs=5127=5130

REVISION DETAIL
  https://phabricator.kde.org/D2152

AFFECTED FILES
  src/lib/marble/graphicsview/MarbleGraphicsItem.cpp

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: stassats, #marble, nienhueser, rahn
Cc: marble-devel
___
Marble-devel mailing list
Marble-devel@kde.org
https://mail.kde.org/mailman/listinfo/marble-devel

[Marble-devel] [Differential] [Request, 2 lines] D2151: Set NSHighResolutionCapable in mac/Info.plist

[stassats (Stas Boukarev)]

stassats created this revision.
stassats added reviewers: Marble, nienhueser, rahn.
stassats set the repository for this revision to rMARBLE Marble.

REPOSITORY
  rMARBLE Marble

REVISION DETAIL
  https://phabricator.kde.org/D2151

AFFECTED FILES
  src/mac/Info.plist

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: stassats, #marble, nienhueser, rahn
Cc: marble-devel
___
Marble-devel mailing list
Marble-devel@kde.org
https://mail.kde.org/mailman/listinfo/marble-devel

[Marble-devel] [Differential] [Request, 0 lines] D2150: Make a full set of Mac icons.

[stassats (Stas Boukarev)]

stassats created this revision.
stassats added reviewers: Marble, nienhueser, rahn.
stassats set the repository for this revision to rMARBLE Marble.

REVISION SUMMARY
  Provide all the sizes required by Apple.

REPOSITORY
  rMARBLE Marble

REVISION DETAIL
  https://phabricator.kde.org/D2150

AFFECTED FILES
  src/mac/Contents/Resources/Marble.icns

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: stassats, #marble, nienhueser, rahn
Cc: marble-devel
___
Marble-devel mailing list
Marble-devel@kde.org
https://mail.kde.org/mailman/listinfo/marble-devel

Re: ECL on very small chips?

[Stas Boukarev]

On Fri, Mar 25, 2016 at 11:24 AM, Andreas Thiele  wrote:
> Hello,
>
>
>
> can I use ECL to write software for a chip without OS?
>
>
>
> In my case I’d like to write software for NXP1769 which is ARM Cortex M3,
> 64kB Ram, 512kB Flash.
ECL takes up much more RAM than that.
And any full common lisp implementation would have trouble with that.

-- 
With best regards, Stas.

Re: Windows will no longer be supported by ASDF, or ASDF, Windows, Cygwin -- oh, my!

[Stas Boukarev]

Stas Boukarev <stass...@gmail.com> writes:

> Robert Goldman <rpgold...@sift.net> writes:
>
>> On 3/21/16 Mar 21 -9:34 AM, Stas Boukarev wrote:
>>> I never liked the idea of cygwin, mingw (via msys2) seems to be
>>> working pretty well for me.
>>
>> Any chance you could grab a copy of the git repo and run the tests on
>> Windows?
>>
>> I'm relatively confident that everything works the same across lisp
>> implementations on Windows now.  The same tests fail for me everywhere.
>>
>> The tests failing, AFAICT, are mostly due to Cygwin environment bleeding
>> into the environment used by the Lisp (which interacts with Windows
>> through CMD.EXE).  My guess is that these will fail in pretty much the
>> same way under mingw, but I have never used mingw, so I can't really
>> say.  Does it have its own pathname syntax, the way cygwin does?  (You
>> can tell I don't use windows -- except for testing ASDF!).
> Two tests fail:
> test-run-program.script test-sysdef-asdf.script
>
> test-sysdef-asdf fails because sb-ext:run-program doesn't yet support
> output redirection on windows.
>
> test-run-program because it can't find "echo" which turns out to be a
> shell script with echo "$@", cmd.exe has trouble executing that.
> Found some bsd echo.c, compiled and stuffed it instead of the shell
> script, the test now passes.
>
> So, ASDF works as much as it can be expected to work.
Actually, the sysdef-asdf test not only succumbs to missing output
redirection it also does
  0: (SB-EXT:RUN-PROGRAM "C:\\Windows\\System32\\cmd.exe"
 ("/c"
  "\"C:\\Windows\\System32\\cmd.exe\" /c make.bat driver
_files")
 :INPUT T :OUTPUT T :WAIT T :ALLOW-OTHER-KEYS T :ERROR
 T :IF-INPUT-DOES-NOT-EXIST :ERROR :IF-OUTPUT-EXISTS
 :OVERWRITE :IF-ERROR-EXISTS :OVERWRITE :SEARCH T
 :IF-OUTPUT-DOES-NOT-EXIST :CREATE
 :IF-ERROR-DOES-NOT-EXIST :CREATE :WAIT T :INPUT
 :INTERACTIVE :OUTPUT :INTERACTIVE :ERROR-OUTPUT
 :INTERACTIVE :INPUT :INTERACTIVE :ERROR-OUTPUT
 :INTERACTIVE :IF-INPUT-DOES-NOT-EXIST :ERROR
 :IF-OUTPUT-EXISTS :OVERWRITE :IF-ERROR-OUTPUT-EXISTS
 :OVERWRITE :ELEMENT-TYPE :DEFAULT :EXTERNAL-FORMAT
 :UTF-8 :FORCE-SHELL T :DIRECTORY
 #P"c:/Users/stas/asdf/" :OUTPUT :INTERACTIVE)


Which results in
'\"C:\Windows\System32\cmd.exe\"' is not recognized as an internal or external c
ommand,
operable program or batch file.

the current asdf in SBCL doesn't do that.

 
-- 
With best regards, Stas.

Re: Windows will no longer be supported by ASDF, or ASDF, Windows, Cygwin -- oh, my!

[Stas Boukarev]

Robert Goldman <rpgold...@sift.net> writes:

> On 3/21/16 Mar 21 -9:34 AM, Stas Boukarev wrote:
>> I never liked the idea of cygwin, mingw (via msys2) seems to be
>> working pretty well for me.
>
> Any chance you could grab a copy of the git repo and run the tests on
> Windows?
>
> I'm relatively confident that everything works the same across lisp
> implementations on Windows now.  The same tests fail for me everywhere.
>
> The tests failing, AFAICT, are mostly due to Cygwin environment bleeding
> into the environment used by the Lisp (which interacts with Windows
> through CMD.EXE).  My guess is that these will fail in pretty much the
> same way under mingw, but I have never used mingw, so I can't really
> say.  Does it have its own pathname syntax, the way cygwin does?  (You
> can tell I don't use windows -- except for testing ASDF!).
Two tests fail:
test-run-program.script test-sysdef-asdf.script

test-sysdef-asdf fails because sb-ext:run-program doesn't yet support
output redirection on windows.

test-run-program because it can't find "echo" which turns out to be a
shell script with echo "$@", cmd.exe has trouble executing that.
Found some bsd echo.c, compiled and stuffed it instead of the shell
script, the test now passes.

So, ASDF works as much as it can be expected to work.
-- 
With best regards, Stas.

Re: Windows will no longer be supported by ASDF, or ASDF, Windows, Cygwin -- oh, my!

[Stas Boukarev]

I never liked the idea of cygwin, mingw (via msys2) seems to be
working pretty well for me.

On Mon, Mar 21, 2016 at 5:32 PM, Robert Goldman <rpgold...@sift.net> wrote:
> On 3/21/16 Mar 21 -8:59 AM, Stas Boukarev wrote:
>> On Mon, Mar 21, 2016 at 4:16 PM, Robert Goldman <rpgold...@sift.net> wrote:
>>> On 3/20/16 Mar 20 -7:07 PM, Stas Boukarev wrote:
>>>
>>>> Then I guess SBCL holding back on ASDF upgrades is a good strategy after 
>>>> all.
>>>>
>>> Actually, no.
>>>
>>> The state of affairs on Windows is no worse than before.  My going back
>>> to the shell-script based testing simply REVEALS that ASDF and UIOP have
>>> never worked properly on Windows + Cygwin.  Nothing about that has
>>> changed: if you run a CL implementation from inside Cygwin, it will
>>> inherit a Cygwin environment.  Then RUN-PROGRAM will try to run local
>>> programs using CMD.EXE, with an environment set up for Cygwin.  If
>>> you're lucky, it might work.  But it's likely that the environment will
>>> have bad pathnames in it, and your use of RUN-PROGRAM will fail.
>>>
>>> Nothing there has changed.  The only thing that has changed about that
>>> is that I have announced it.
>>>
>>> So, no, a simple dragging of the feet will not fix this problem.
>>>
>>> The only thing that will fix this problem will be for someone who cares
>>> about Lisp on Windows to commit some time to helping me get ASDF to work
>>> properly on Windows.
>>>
>>> Meanwhile, not updating means that you will fail to see bug fixes like
>>> the recent one that prevents ASDF from causing a stack overflow in the
>>> presence of cycles in the file system (which can be created by symbolic
>>> links, for example).  I have seen more than one bug report about this
>>> from an SBCL user.
>>>
>>> Don't kid yourself that there's an easy answer.
>>>
>> I don't use cygwin on windows, does that mean I'm in the clear?
>>
>
> I don't know.  I don't have a way to run the tests without Cygwin.
> That's why I need help.  Need someone with a minimal level of competence
> in Windows bat-files to figure out how to run the tests there.
>
> The current test and build suites are based on Make and bash.  So they
> essentially don't work w/o Cygwin (maybe they would work with MinGW? I
> don't know). That means that Windows is essentially not tested.
>
> Again, this is not something new.  Essentially, Windows has never been
> effectively tested.  Dave Cooper and I have tried to test on Windows,
> but only with Cygwin.
>
> Is it possible that someone could make this work with Powershell? I
> don't really know much about the current status of the windows platform.
>  My impression is that it would be pretty difficult to port to make
> everything work with just CMD.EXE, because it's so different and is
> relatively crude.
>
> R
>



-- 
With best regards, Stas.

Re: Windows will no longer be supported by ASDF, or ASDF, Windows, Cygwin -- oh, my!

[Stas Boukarev]

On Mon, Mar 21, 2016 at 4:16 PM, Robert Goldman <rpgold...@sift.net> wrote:
> On 3/20/16 Mar 20 -7:07 PM, Stas Boukarev wrote:
>
>> Then I guess SBCL holding back on ASDF upgrades is a good strategy after all.
>>
> Actually, no.
>
> The state of affairs on Windows is no worse than before.  My going back
> to the shell-script based testing simply REVEALS that ASDF and UIOP have
> never worked properly on Windows + Cygwin.  Nothing about that has
> changed: if you run a CL implementation from inside Cygwin, it will
> inherit a Cygwin environment.  Then RUN-PROGRAM will try to run local
> programs using CMD.EXE, with an environment set up for Cygwin.  If
> you're lucky, it might work.  But it's likely that the environment will
> have bad pathnames in it, and your use of RUN-PROGRAM will fail.
>
> Nothing there has changed.  The only thing that has changed about that
> is that I have announced it.
>
> So, no, a simple dragging of the feet will not fix this problem.
>
> The only thing that will fix this problem will be for someone who cares
> about Lisp on Windows to commit some time to helping me get ASDF to work
> properly on Windows.
>
> Meanwhile, not updating means that you will fail to see bug fixes like
> the recent one that prevents ASDF from causing a stack overflow in the
> presence of cycles in the file system (which can be created by symbolic
> links, for example).  I have seen more than one bug report about this
> from an SBCL user.
>
> Don't kid yourself that there's an easy answer.
>
I don't use cygwin on windows, does that mean I'm in the clear?

-- 
With best regards, Stas.

Re: Windows will no longer be supported by ASDF, or ASDF, Windows, Cygwin -- oh, my!

[Stas Boukarev]

On Sun, Mar 20, 2016 at 11:23 PM, Robert Goldman  wrote:
> I can set the configuration properly from an environment variable.
>
> But there are a number of tests that then reach out into the environment
> and try to reconfigure the source or otherwise read information.
>
> These are test-program.script test-try-refinding.script
> test-utilities.script
>
> None of these work properly when Lisp is running under cygwin.
>
> I'm inclined to think that this is an ASDF+Windows problem, and not a
> problem to be fixed in the tests.  If you run a Lisp under cygwin, and
> you call some of these functions, they should simply error out, because
> the cygwin environment is going to give the lisp pathnames that it can't
> handle.
>
> Further, (a) we don't know how to call out to cygwin; (b) we can't call
> out to CMD.EXE when running under cygwin, because we have a polluted
> environment; and (c) UIOP cannot detect when it is running under cygwin.
>
> Under the circumstances, RUN-PROGRAM simply doesn't run reliably under
> cygwin.  Worse, since we can't detect Cygwin, we really can't reliably
> run under windows at all, since we don't know when these functions will
> and won't work.
>
> This suggests the following:
>
> 1. We desperately need ASDF to be able to detect when it's running under
> cygwin, so it can at least error out when it's going to function wrong.
>
> 2. I don't know how to program make.bat.  I will not be learning how to
> program make.bat.  The test scripts that I can run are shell scripts.  I
> have not been able to make Fare's lisp build and test scripts work and I
> am no longer trying to make them work at all, ever, anywhere.  I don't
> believe they work any better under Cygwin, anyway.
>
> Ergo, if ASDF works on Windows, it will only be a matter of luck.
>
> Ergo, ASDF needs a windows tester and maintainer.  I quite simply
> decline to perform this function.  Someone who wants ASDF to work on
> Windows should step up.
>
> Unless someone steps up by the end of March, all further ASDF releases,
> starting with 3.1.7 will be officially Windows non-supporting.  Windows
> patches and bug reports will be accepted.  I will not make any attempt
> to fix Windows ASDF bugs myself.  I will make only those Windows tests
> that I can make under Cygwin.
>
Then I guess SBCL holding back on ASDF upgrades is a good strategy after all.

-- 
With best regards, Stas.

Re: [Gcc-cfarm-users] postgres on gcc112

[Stas Boukarev]

On Wed, Feb 10, 2016 at 1:34 PM, Stefan Ring  wrote:
> On Wed, Feb 10, 2016 at 4:44 AM, Noah Misch  wrote:
>> Killing them was the right decision.  Thank you.  Like all my cfarm batch
>> testing, the processes had setpriority(PRIO_MAX).  Perhaps I/O load remained
>> high enough to ruin things.
>
> Unfortunately, process priority is absolutely worthless on machines
> with hyperthreading. The other day I witnessed someone using all 64
> virtual cores of gcc110 (the POWER7 machine), and it was godawfully
> slow to work with.
Sorry about that. But it did allow me to trigger the bug I was looking for.

-- 
With best regards, Stas.

___
Gcc-cfarm-users mailing list
Gcc-cfarm-users@gna.org
https://mail.gna.org/listinfo/gcc-cfarm-users

Re: what is the length of a long (motivated by GSL2.1 and GSLL)

[Stas Boukarev]

Mirko Vukovic  writes:

> This message has two audiences:  One the general CFFI group, and second the
> GSL maintainer.
>
> This is using latest CCL and SBCL on 64-bit Windows 7, and MSYS2 running
> 64-bit MinGW and its GSL2.0 and 2.1.
>
> Running GSL 2.0 and 2.1 under GSLL resulted in exception violations.  I
> could eliminate them by specifying the length of an integer as 8 instead of
> 4 bytes.
>
> My question has to do with the origin of this specification, since it is
> derived from CFFI and GSLL, not hard-coded.
>
> Specifically, in GSLL, the following code in init/types.lisp:
> (case (cffi:foreign-type-size :long)
>   *(8 (push :int64 *features*))*
>   *(4 (push :int32 *features*))*)
>
> evaluates to 4, pushing :int32 into *features*.  Here is some additional
> output of cffi:foreign-type-size on my machine:
>
> GSL> (cffi:foreign-type-size :double)
> 8
> GSL> (cffi:foreign-type-size :long)
> 4
> GSL> (cffi:foreign-type-size :long-long)
> 8
> GSL> (cffi:foreign-type-size :int)
> 4
>
> This feature eventually makes its way to other code in GSLL.  In the Linear
> Algebra module, the function make-permutation (in data/permutation.lisp)
> has this line:
> (make-instance
>  'permutation
>  :element-type '(unsigned-byte *#+int64 64* *#+int32 32*)
>  :dimensions (if (typep n 'permutation) (grid:dimensions n) (list n)
>
> In my environment element type resulted in unsigned-byte 32.
>
> When I hard-coded my features to :int64 (and unsigned-byte 64), all the
> exception errors disappeared.
>
> I hope this gives enough background to fix this error (either in my setup,
> gsll, or cffi).
long on 64-bit windows is indeed 4-byte long, so it cannot be used to
determine word length.

I would suggest using (cffi:foreign-type-size :pointer) instead.
I would also suggest using DEFTYPE:
(deftype word ()
  `(unsigned-byte ,(* (cffi:foreign-type-size :pointer) 8)))

-- 
With best regards, Stas.

Re: [Ecls-list] porting to ecl question: lambda lists are not congruent

[Stas Boukarev]

Daniel Kochmański jackdan...@hellsgate.pl writes:

 Hello,

 problem is that you define two methods #'build-hmeq, where parameter
 lists are not congruent. Quick fix is to def generic method inbefore
 like this:

 (defgeneric build-hmeq (keyword lrdct key allow-other-keys)
   (:documentation xyz))

 apparently tested lisp implementations make generic with
 allow-other-keys automatically.
Moreover, this is a bug in ECL, the generic function created through a
DEFMETHOD with key should have no key arguments, just key.
-- 
With best regards, Stas.

--
___
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list

Re: [Ecls-list] porting to ecl question: lambda lists are not congruent

[Stas Boukarev]

Daniel Kochmański jackdan...@hellsgate.pl writes:

 Hello,

 problem is that you define two methods #'build-hmeq, where parameter
 lists are not congruent. Quick fix is to def generic method inbefore
 like this:

 (defgeneric build-hmeq (keyword lrdct key allow-other-keys)
   (:documentation xyz))

 apparently tested lisp implementations make generic with
 allow-other-keys automatically.
There should be no allow-other-keys, just key in the defgeneric, which
will allow all the keys specified by the methods. allow-other-keys
will allow any keys.

-- 
With best regards, Stas.

--
___
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list

Re: status of openmcl and :ccl-1.11-sockets feature

[Stas Boukarev]

CL does guarantee it. Each form is read one by one. And eval-when causes
evaluation.
If that didn't work, how do you imagine IN-PACKAGE would work?

On Wed, Apr 15, 2015 at 4:16 AM, Mark H. David m...@clozure.com wrote:

 I see there's code to add feature :ccl-1.11-sockets and to use it via a
 read-time feature check in the same file. The file is
 backend/openmcl.lisp.  I don't think this can work reliably.  It seems to
 work, but I don't think Common Lisp guarantees it.

 The code is

 (eval-when (:compile-toplevel :load-toplevel :execute)
   (when (find-class 'ccl::ip6-socket-address nil)
 (pushnew :ccl-1.11-sockets *features*)))

 I think a much more robust solution would be for this to go in an earlier
 file that is guaranteed to be loaded before backend/openmcl.lisp is
 compiled.

 Can one of the developers review this?

 Also, any word on when this will propagate to Quicklisp?

 Thanks,

 Mark




-- 
With best regards, Stas.

Re: [Ecls-list] [maintainership]

[Stas Boukarev]

On Sat, Feb 21, 2015 at 11:57 PM, Daniel Kochmański
jackdan...@hellsgate.pl wrote:
 Also, is anyone aware, how to edit ecls.sourceforge.net site? (it's
 different then site accessed with SF search).
http://sourceforge.net/p/forge/documentation/Project%20Web%20Services/
and
http://sourceforge.net/p/forge/documentation/Release%20Files%20for%20Download/

-- 
With best regards, Stas.

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk
___
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list

Re: [cffi-devel] C to Lisp

[Stas Boukarev]

Greg Bennett gwbenn...@sentex.ca writes:

 Good morning,
 I (think I) might be close to getting a result in having a C function
 return its output to Lisp. I shall be very grateful for comments and
 corrections to what I have done, and thank readers for their patience.

 Here is the C-function from which I wish to get the result  Hello Lisp
 from C  on the lisp side:
 /* Hello.c  program */


 #includestdio.h

 void Hello(void)
 {
 printf(Hello Lisp from C\n);
 return 0 ;

 }

 At the end of the process, I hope to be able to do this on the Lisp
 side:
 (defcfun (Hello HiFromC) (:void))
 and then
 (HiFromC) - Hello Lisp from C

 Both C and Lisp sessions are below in case details are relevant.
 Somewhere I have missed a critical element.

 Thanks to a message from Luis Oliveira pointing me to the necessity of
 using a shared library as the intermediary between C and Lisp. There
 seem to be as many recipes for creating such libraries as there are
 posters of the topic, and as many variations on the code too. I have
 put together the C side following very much this page:
  www.cprogramming.com/tutorial/shared-libraries-linux-gcc.html

 In file /home/gwbennett/Hello.h
 #ifndef Hello_h__
 #define  Hello_h__

 extern void Hello(void);

 #endif  // Hello_h__

 In file /home/gwbennett/Hello.c
 /* Hello  program */


 #includestdio.h

 void Hello(void)
 {
 printf(Hello Lisp from C\n);
 return 0 ;

 }

 In file main.c
 /* This is main.c to go with Hello.c,h */
 #include stdio.h
 #include Hello.h

 int main (void)
 {
   Hello();
   return 0;
 }

 Then
 gcc -c -Wall -Werror -fpic Hello.c - OK
 gcc -shared -o libfHello.so Hello.o - OK
 gcc -L/home/gwbennett -Wall -o test main.c -lHello - OK

 Step 4 of the above page is about making the library visible.
 I have tried all 3 routes with the same results; at the moment I have
 taken the path of installing libHello.so in /usr/lib (and
 in /usr/loca/lib too)as described in the Section  Using ldconfig to
 modify ld.so

 gcc -Wall -o test main.c -lfoo - OK
 ldd test | grep foo - /usr/locl/lib/libHello.so (0x7f946c0c4000)
 ./test - Hello Lisp from C

 so things seem to work down the C-side

 On the Lisp side I (hope I) am following the cffi manual page 10. I
 assume that cffi looks for shared libraries in the same sort of 'system'
 places as C, but just in case, see page 106 on
 *foreign-library-directories*.

 Start ccl version 1.9-r15972M (LinuxX8664)
 (require :cffi) - OK
 (defpackage :cffi-user
   (:use :common-lisp :cffi)) - OK
 (in-package :cffi-user) - OK
 ;P106
 (pushnew #P/usr/lib *foreign-library-directories* :test #'equal) - OK
 (pushnew #P/usr/local/lib *foreign-library-directories* :test #'equal)
 - OK
 (load-foreign-library '(:default LibHello)) - OK
 ;; I think I should be able to define the C - Lisp name function
 (defcfun (Hello HiFromC) (:void)) - HIFROMC
 ;; and execute it to get the message
 (HiFromC) - NIL

 ;; .. so evidently I have not completely understood what is necessary to
 achieve the desired result.
Are you aware of the difference between printing to the standard output
and returning a result?

And all you have to do is:
#include stdio.h

void hello () {
 printf(Hello Lisp from C\n);
}

gcc foo.c -fPIC -o foo.so

? (cffi:load-foreign-library /tmp/foo.so)
#FOREIGN-LIBRARY FOO.SO-6780 foo.so
? (cffi:foreign-funcall hello)
Hello Lisp from C
NIL
?

If you still don't see any output,
just add fflush(stdout);

-- 
With best regards, Stas.

Re: [asdf-devel] unsubscribe

[Stas Boukarev]

Brett van de Sande b...@asu.edu writes:

 Two things:

 The links to asdf-devel and asdf-announce on 
 http://common-lisp.net/project/asdf/#mailing-lists
 are dead.
That's a feature.

 Also, how do I unsubscribe?
By sending a message to asdf-devel+unsubscr...@common-lisp.net

-- 
With best regards, Stas.

Re: [asdf-devel] Please test before releasing ASDF 3.0.0 - Also, resigning again

[Stas Boukarev]

Faré fah...@gmail.com writes:

 Dear Lisp hackers,

 I'd like to release ASDF 3.0 next week (maybe even later this week).
 Can you test ASDF before I do?
I get asdf-pathname-test.script failure on SBCL:

These two expressions yield paths that are not pathname-equal
the first expression (RESOLVE-LOCATION '(/foo bar baz)) yields this:
  #P/bar/baz
  (:HOST #SB-IMPL::UNIX-HOST {100023F223} :DEVICE NIL :DIRECTORY
   (:ABSOLUTE bar) :NAME baz :TYPE :UNSPECIFIC :VERSION NIL)

the other expression #P/foo/bar/baz yields that:
  #P/foo/bar/baz
  (:HOST #SB-IMPL::UNIX-HOST {100023F223} :DEVICE NIL :DIRECTORY
   (:ABSOLUTE foo bar) :NAME baz :TYPE NIL :VERSION :NEWEST)

-- 
With best regards, Stas.

Re: [asdf-devel] Please test before releasing ASDF 3.0.0 - Also, resigning again

[Stas Boukarev]

Faré fah...@gmail.com writes:

 Works for me. Weird. Which version of SBCL are you using?
1.1.6.14-76e4485

-- 
With best regards, Stas.

Re: [asdf-devel] Please test before releasing ASDF 3.0.0 - Also, resigning again

[Stas Boukarev]

Faré fah...@gmail.com writes:

 Works for me. Weird. Which version of SBCL are you using?
I also have a file /foo, if that matters.

-- 
With best regards, Stas.

Re: Is this supposed to be kosher/halal/conformant?

[Stas Boukarev]

Antoniotti Marco antoniotti.ma...@disco.unimib.it writes:

  (defmacro foo (n optional ((s key d f) '(4 :f 33)))
 `(list ,f ,n ,s ,d))


 it appears to work on SBCL, CCL and LW (just changed a few things and do not 
 have an Allegro running)

 It is nice, but I believe that the CLHS says otherwise.
What do you mean, CLHS says otherwise?
See
http://www.lispworks.com/reference/HyperSpec/Body/03_ddab.htm

And why is this in pro@?

-- 
With best regards, Stas.

Re: Is this supposed to be kosher/halal/conformant?

[Stas Boukarev]

Antoniotti Marco antoniotti.ma...@disco.unimib.it writes:

 On Apr 13, 2013, at 20:02 , Stas Boukarev stass...@gmail.com
  wrote:

 Antoniotti Marco antoniotti.ma...@disco.unimib.it writes:
 
 (defmacro foo (n optional ((s key d f) '(4 :f 33)))
`(list ,f ,n ,s ,d))
 
 
 it appears to work on SBCL, CCL and LW (just changed a few things and do 
 not have an Allegro running)
 
 It is nice, but I believe that the CLHS says otherwise.
 What do you mean, CLHS says otherwise?
 See
 http://www.lispworks.com/reference/HyperSpec/Body/03_ddab.htm

 Good catch.

 And yet...

 http://www.lispworks.com/documentation/HyperSpec/Body/03_dd.htm
And yet, what? Nothing stated there contradicts the previous section.


 And why is this in pro@?

 Because I am a pro (albeit a small one) and this is a matter of 
 inconsistencies in the spec?

It would appear to me that questions, which could be resolved by careful
reading of the spec, are out of scope of this mailing list, but what do I
know?


-- 
With best regards, Stas.

Re: [pro] best practices on type safety of/for generic functions

[Stas Boukarev]

John Morrison john.nmi.morri...@gmail.com writes:

 Hi All;

 This is probably a dumb question, but here goes.

 John Alan McDonald (Hi, John, if you're on this list!) has graciously
 consented to let me try to revive some almost 20 year old CL software (
 Arizona http://home.comcast.net/~johnamcdonald/jamcdonald0/az93.pdf).
 SBCL doesn't seem to like type-related declarations in defgeneric forms
 (per the 
 spechttp://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/Body/mac_defgeneric.html#defgeneric).
 And there are a lot of defgenerics of the form:

 (declaim (declaration :returns)) ;; OK, only once, but then used
 repeatedly...

 (defgeneric interactor-role-cursor (interactor role)
   (declare (type Interactor interactor)
(type (or Interactor-Role Null) role)
(:returns (type xlib:Cursor)))
   (:documentation
Returns the cursor to be used when this Role is current.))

 (defmethod interactor-role-cursor ((interactor Interactor)
(role Interactor-Role))
   The default cursor
   (xlt:window-cursor (interactor-window interactor) :target))

 I did certainly benefit from some of the runtime errors generated as a
 result of the type declarations of some of the defmethods and defuns in my
 efforts to update the clx parts of the software.

 What is best practice, then, as regards trying to provide useful
 type-related information associated with generic functions?  Or have I been
 so brain-damaged by C++/Java/etc that I am thinking about the problem-space
 entirely the wrong way, and thus my solution-space question is entirely
 meaningless?
The portable equivalent would be
(declaim (ftype (function (interactor (or interactor-role null)) xlib:cursor)
interactor-role-cursor))

-- 
With best regards, Stas.

___
pro mailing list
pro@common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/pro

Re: [asdf-devel] printing the symbol asdf:defsystem for .asd file

[Stas Boukarev]

Dave Cooper david.coo...@genworks.com writes:

 So I am using ASDF 2.31 which puts the symbol defsystem into
 asdf/defsystem package instead of plain asdf package (Franz already
 includes ASDF 2.31 in their patches for Allegro CL).

 I have a little utility which emits the .asd files for me, with a form like:

   `(asdf:defsystem ,(something-to-make-my-system-name) :description blah
 … )

 and now the asdf:defsystem symbol is coming out as asdf/defsystem:defsystem
 instead,

 which makes the .asd file non backwards-compatible with slightly older asdf
 versions,

 because (symbol-package 'asdf:defsystem) -- #The asdf/defsystem package


 So the Question is, what is the best way to get asdf:defsystem to print as
 asdf:defsystem,

 when its home package is :asdf/defsystem and apparently it is now just
 re-exported from :asdf.


 Or should this symbol now be officially printed as asdf/defsystem:defsystem
 ?


 Or should I put some (in-package ...) statement at the top of the .asd
 file, and use plain defsystem with no package prefix?


 Of course I think for the time being the .asd file should be compatible
 with all ASDF versions from recent history...
You don't need to have prefixes already, when .asd is loaded ASDF
creates a temporary package, which uses ASDF package.

-- 
With best regards, Stas.

___
asdf-devel mailing list
asdf-devel@common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel

Re: [asdf-devel] printing the symbol asdf:defsystem for .asd file

[Stas Boukarev]

Faré fah...@gmail.com writes:

: Dave Cooper
 I have a little utility which emits the .asd files for me, with a form like:

   `(asdf:defsystem ,(something-to-make-my-system-name) :description blah
 … )

 If you print that form while *package* is bound to something that uses ASDF,
 (such as ASDF-USER, on 2.31), then it will omit the prefix.

 Or should I put some (in-package ...) statement at the top of the .asd
 file, and use plain defsystem with no package prefix?

: stassats
 You don't need to have prefixes already, when .asd is loaded ASDF
 creates a temporary package, which uses ASDF package.

 In ASDF1 and ASDF2, indeed, .asd files are read from
 a temporary package ASDF~D that uses ASDF.
 In ASDF3, we're using a permanent package ASDF-USER instead,
 and usual hygiene rules apply.
So, if you define your own operation classes, you need to create a new
package?

-- 
With best regards, Stas.

___
asdf-devel mailing list
asdf-devel@common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel

Re: [cffi-devel] Release blockers

[Stas Boukarev]

Anton Vodonosov avodono...@yandex.ru writes:

 23.02.2013, 20:40, Stelian Ionescu sione...@cddr.org:
 On Sat, 2013-02-23 at 14:54 +, Luís Oliveira wrote:

  On Sat, Feb 23, 2013 at 2:40 PM, Stelian Ionescu sione...@cddr.org wrote:
  What is the minimum necessary that needs to be done(bugs to be fixed,
  etc...) to make a new release ? I want to dedicate this weekend to
  release CFFI because that blocks too many projects that depend on the
  new features, IOLib in primis.
  This one would be nice to fix: 
 https://bugs.launchpad.net/cffi/+bug/1131578.

 Bug closed. It took me two hours to notice the error :(

 How about release then? In addition to IOLib, CFFI head contains now a fix 
 for ABCL,
 so that many projects will work on ABCL

It was released a week ago.

-- 
With best regards, Stas.

___
cffi-devel mailing list
cffi-devel@common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel

Re: [asdf-devel] Is is possible to not have ASDF output build-report files and foo.bar-warnings files?

[Stas Boukarev]

Gary King gwk...@metabang.com writes:

 An admittedly quick look at the source didn't ring any bells for me.
(setf asdf:*warnings-file-type* nil)

-- 
With best regards, Stas.

___
asdf-devel mailing list
asdf-devel@common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel

Re: [alexandria-devel] Implementation of DELETE-FROM-PLIST

[Stas Boukarev]

Zach Beane x...@xach.com writes:

 James M. Lawrence llmjj...@gmail.com writes:

 Using two loops seems awkward to me. How about one?

 (defun delete-from-plist (plist rest keys)
   (loop with head = plist
 with tail = nil
 for (key . rest) on plist by #'cddr
 do (assert rest () Expected a proper plist, got ~S plist)
(if (member key keys :test #'eq)
(let ((next (cdr rest)))
  (if tail
  (setf (cdr tail) next)
  (setf head next)))
(setf tail rest))
 finally (return head)))

 I mention this for completeness and novelty, not for suitability:

   (defun sans (plist rest keys)
 (let ((sans ()))
   (loop
 (let ((tail (nth-value 2 (get-properties plist keys
   ;; this is how it ends
   (unless tail
 (return (nreconc sans plist)))
   ;; copy all the unmatched keys
   (loop until (eq plist tail) do
 (push (pop plist) sans)
 (push (pop plist) sans))
   ;; skip the matched key
   (setq plist (cddr plist))

 I don't think I've seen GET-PROPERTIES and NRECONC outside this
 function.

 I got it from here:
 http://xach.com/naggum/articles/3247672165664225%40naggum.no.html
If striving for shortness:

(defun delete-from-plist (plist rest keys)
  (dolist (key keys plist)
(remf plist key)))

-- 
With best regards, Stas.

___
alexandria-devel mailing list
alexandria-devel@common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/alexandria-devel

Re: [alexandria-devel] Implementation of DELETE-FROM-PLIST

[Stas Boukarev]

Robert Smith q...@symbo1ics.com writes:

 On Sat, Feb 23, 2013 at 4:19 PM, Stas Boukarev stass...@gmail.com wrote:
 It's wrong because it's completely useless, why would anyone use
 delete-from-plist without using the value returned by it, if the
 original list it modifies has the wrong result? Having to prepend two
 NILs is just bogus.

 1. Because some people like or prefer to modify data structures
 (especially when you have elaborate data structures), and not
 bindings.
Well, those people should learn that it's not possible in
general. Particularly with lists, because of NIL.

 2. Having to prepend two NILs is fine I think. Yes it is hacky, but I
 don't see any inherent issue with it. It just establishes a (few)
 conses that act as the head or entry point to the list.
What if the key you want to remove is NIL?

 But that part shouldn't be in alexandria (or any sane library, for that
 matter) either way, because it encourages erroneous usage, seemingly
 doing the right thing, but breaks when it comes to returning NIL.

 I don't think it's erroneous. We aren't conflating the ideas of
 modifying a data structure and modifying a binding. By not doing that
 extra mutation, we rely on the user to finish the job by re-setting
 their variable to the new value.
There's no other way to obtain the correct results otherwise. Having it
to work in 99% is worse than having it not to work at all, because
people might forget about the remaining 1% case more easily. So you end
up with doing extra work which has no use. The goal is simplicity, not
having to memorize in which cases it's alright and which it's not. Just
use the return value and be merry.

 And there's alexandria:delete-from-plistf for people who are afraid of
 an extra SETF.

 In this, we are trading a purely functional (i.e., non-special/macro)
 solution for a macro solution. Doesn't that go against the grain of
 the prevalent ideology of Lisp?
There's no trading, delete-from-plistf is just a define-modify-macro for
delete-from-plist.

-- 
With best regards, Stas.

___
alexandria-devel mailing list
alexandria-devel@common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/alexandria-devel

Re: [asdf-devel] CMUCL fails tests (Was Re: Just pulled an update and now CCL fails the tests)

[Stas Boukarev]

Faré fah...@gmail.com writes:

 ABCL hackers: is there such a thing as getcwd in ABCL,
 and if so how do I get to it?
(jstatic getProperty java.lang.System user.dir)

-- 
With best regards, Stas.

___
asdf-devel mailing list
asdf-devel@common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel

Re: [Ecls-list] Ecl PARSE-NAMESTRING unable to handle unicode path name

[Stas Boukarev]

Peter Enerccio enerc...@gmail.com writes:

 Hello, I am trying to pass unicode string into PARSE-NAMESTRING, however,
 it doesn't work.

 (parse-namestring aAaaajあ)

 Cannot coerce string aAaaajあ to a base-string
[Condition of type SIMPLE-ERROR]

 List of features:
  *features*
 (:SWANK :SERVE-EVENT :PROFILE :LINUX :FORMATTER
  :ECL-WEAK-HASH :LITTLE-ENDIAN :ECL-READ-WRITE-LOCK
  :LONG-LONG :UINT64-T :UINT32-T :UINT16-T
  :RELATIVE-PACKAGE-NAMES :LONG-FLOAT :UNICODE :DFFI
  :CLOS-STREAMS :CMU-FORMAT :UNIX :ECL-PDE :DLOPEN
 :CLOS
  :THREADS :BOEHM-GC :ANSI-CL :COMMON-LISP
  :IEEE-FLOATING-POINT :PREFIXED-API :FFI :X86_64
  :COMMON :ECL)

 Version of ecl:

  *features*ECL (Embeddable Common-Lisp) 12.12.1
 (git:5b7258e8c5ddd1e3f4600d1dfb3e4e3b860d2c84)

 Any idea what to do?
See http://sourceforge.net/p/ecls/bugs/237/

-- 
With best regards, Stas.

--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnmore_123012
___
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list

Re: [Ecls-list] Bug: can't print-object hash-table

[Stas Boukarev]

Stas Boukarev stass...@gmail.com writes:

 Stanislav Frolov frolosof...@gmail.com writes:

 It seems to print functions do not call print-object method for hash-table 
 and 
 other standard types. I would like to see some human-readable representation 
 of hash tables.

 (defmethod print-object ((hash hash-table) stream)
  (format stream 42))
 ;compiled

 (print (make-hash-table))
 ;evaluated = #hash-table 0b41ef90

 Reproduced with latest ECL's version from git.
 That's correct, portable programs can't define methods which only
 specialize on standard classes.
See the last point:
http://www.lispworks.com/reference/HyperSpec/Body/11_abab.htm

-- 
With best regards, Stas.

--
Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and
much more. Get web development skills now with LearnDevNow -
350+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122812
___
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list

Re: [Ecls-list] (function * t) type specifier is no longer accepted

[Stas Boukarev]

Juan Jose Garcia-Ripoll juanjose.garciarip...@googlemail.com writes:

 On Fri, Jun 1, 2012 at 12:20 PM, Stas Boukarev stass...@gmail.com wrote:

 As per CLHS,
 http://www.lispworks.com/documentation/lw50/CLHS/Body/04_bc.htm
 * means unspecified part of the type specifier.

 (declaim (ftype (function * integer) f))

 (defun f (a)
  (1+ a))

 and then (compile-file file.lisp)

 ;;; LAMBDA: Illegal lambda list *.


 Actually, the behavior you expect is undefined. While * is used to design
 parts of the type that are general, not specified, the situations in which
 * is used are very precisely marked by the Standard. Note for instance the
 difference between the grammar for the ARRAY type

 http://www.lispworks.com/documentation/lw50/CLHS/Body/t_array.htm#array

 and that of the FUNCTION type

 http://www.lispworks.com/documentation/lw50/CLHS/Body/t_fn.htm

 Only the former allows *

 One could allow ECL to support * by ignoring all function declarations
 where it appears. I presume this would help with certain libraries that use
 these nonstandard types.
Let's revisit this.

I'm not convinced that it is illegal.
http://www.lispworks.com/documentation/lw50/CLHS/Body/04_bc.htm
says
If a type specifier is a list, the car of the list is a symbol, and the
rest of the list is subsidiary type information.
(function ..) fits that.
Now it states Except as explicitly stated otherwise, the subsidiary
items can be unspecified.
Ok, we check
http://www.lispworks.com/documentation/lw50/CLHS/Body/t_fn.htm
nowhere does it state that it's not allowed.

Back to 4.2.3
If a list has one or more unspecified items at the end, those items can
be dropped. If dropping all occurrences of * results in a singleton
list, then the parentheses can be dropped as well (the list can be
replaced by the symbol in its car). For example, (vector double-float *)
can be abbreviated to (vector double-float), and (vector * *) can be
abbreviated to (vector) and then to vector. 

So, just FUNCTION is allowed, but according to the above, it's the same
as (function * *).

It is indeed true that for other compound type specifiers * is
explicitly mentioned as allowed.

But what about cases when it's not allowed?
There's a table of
compound type specifier names but that cannot be used as atomic type
specifiers.
and mod  satisfies  
eql not  values 
member  or

==

and
http://www.lispworks.com/documentation/lw50/CLHS/Body/t_and.htm
* is not permitted as an argument.

eql
http://www.lispworks.com/documentation/lw50/CLHS/Body/t_eql.htm
The object can be *, but if so it denotes itself (the symbol *) and does
not represent an unspecified value.

member
http://www.lispworks.com/documentation/lw50/CLHS/Body/t_member.htm
* can be among the objects, but if so it denotes itself (the symbol *)
and does not represent an unspecified value.

not
http://www.lispworks.com/documentation/lw50/CLHS/Body/t_not.htm
The argument is required, and cannot be *.

or
http://www.lispworks.com/documentation/lw50/CLHS/Body/t_or.htm
* is not permitted as an argument.

http://www.lispworks.com/documentation/lw50/CLHS/Body/t_satisf.htm
The symbol * can be the argument, but it denotes itself (the symbol *),
and does not represent an unspecified value. 

values
http://www.lispworks.com/documentation/lw50/CLHS/Body/t_values.htm
he symbol * may not be among the value-types.

==

So, all of them very explicitly forbid *. FUNCTION just happens to be
the only of compound type-specifiers which can be used as just
function and which doesn't mention *. Now why the type-specifiers above
forbid */have a different meaning? Because it doesn't make sense for it
to appear there. What would (not *) mean? Nonsense. But does it make
sense for FUNCTION to have *? Of course, it would just mean that such a
part can be anything, and indeed just FUNCTION working fine is an
evidence of this. Is it useful? It is, (function * fixnum) denotes that
it accepts whatever but returns a fixnum.
Now somebody might say But you can use (function (rest t) fixnum)
instead, which cannot be said for (vector *), because it has a different
meaning from (vector t). That's true, but (cons *) is equivalent to
(cons t), and yet it's explicitly allowed:
http://www.lispworks.com/documentation/lw50/CLHS/Body/t_cons.htm

And let's look at the other parts of the standard. It has a lot of
instances where things are not explicitly mentioned, but are implied
from other parts, for example:

http://www.lispworks.com/documentation/lw50/CLHS/Body/19_bc.htm
Except as explicitly specified otherwise, for functions that manipulate
or inquire about files in the file system, the pathname argument to such
a function is merged with *default-pathname-defaults* before accessing
the file system (as if by merge-pathnames).

and http://www.lispworks.com/documentation/lw50/CLHS/Body/f_dir.htm
doesn't mention anywhere that it merges the pathname, and yet nobody
disputes that it should.

And it even has the same wording Except as explicitly

Re: [asdf-devel] prepare-op

[Stas Boukarev]

Faré fah...@gmail.com writes:

 Casualties of the cleanup were :feature and :if-component-dep-fails.
 They were just horrible things.

 FYI, the sb-rotate-byte contrib in SBCL uses :if-component-dep-fails.

 I've contacted the SBCL maintainers. Hopefully they will revert to
 #+x86-64 and such until a new asdf is universal. But that begs the
 question: how do we support old versions... and should we try?
SBCL is already change, but if people want to use newer ASDF, then can
also use newer SBCL.

-- 
With best regards, Stas.

___
asdf-devel mailing list
asdf-devel@common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel

Re: [Ecls-list] Spurious unused variable warnings in defmacro

[Stas Boukarev]

Juan Jose Garcia-Ripoll juanjose.garciarip...@gmail.com writes:

 Hi Stas,

 i am creating tickets for both bugs. One is half-solved, but I need this to
 keep myself posted on what I do -- please apologize if I forget to report
 the bug solution to the mailing list. It seems most efficient for me to
 proceed this way.
Is it generally better to report bugs on to the bug-tracker?
-- 
With best regards, Stas.

--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list

[Ecls-list] Strange reader and printer behaviour

[Stas Boukarev]

^ and _ symbols are printed with quotes:
(print '(^ _))
=
(|^| |_|)

Neither of them satisfy the second criterion for potential numbers:
http://www.lispworks.com/reference/HyperSpec/Body/02_caa.htm
The token contains at least one digit.

'. is read as SI:|.|, while it should signal an error.

#.. errors with The variable SI:|.| is unbound.
-- 
With best regards, Stas.

--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list

Re: [Ecls-list] Datetime bug (gmt?)

[Stas Boukarev]

Stanislav Frolov frolosof...@gmail.com writes:

What is the value of localtime() and gmtime() in your
system?

 localtime(0):
 tm_sec 0 
 tm_min 0 
 tm_hour 3 
 tm_mday 1 
 tm_mon 0 
 tm_year 70 
 tm_wday 4 
 tm_yday 0 
 tm_stdst 0

 gmtime(0):
 tm_sec 0 
 tm_min 0 
 tm_hour 0 
 tm_mday 1 
 tm_mon 0 
 tm_year 70 
 tm_wday 4 
 tm_yday 0 
 tm_stdst 0

 Looks like localtime returns 3 hours instead of 4.
 And datetimes for current time_t:

 localtime(NOW):
 tm_sec 46 
 tm_min 15 
 tm_hour 9 
 tm_mday 3 
 tm_mon 7 
 tm_year 112 
 tm_wday 5 
 tm_yday 215 
 tm_stdst 0

 gmtime(NOW):
 tm_sec 46 
 tm_min 15 
 tm_hour 5 
 tm_mday 3 
 tm_mon 7 
 tm_year 112 
 tm_wday 5 
 tm_yday 215   

 tm_stdst 0

 Difference between gmtime and localtime is 4 hours. Bug? Feature?
Well, the difference between 1 January 1970 GMT and 1 January 1970 MSK
is 3 hours.

-- 
With best regards, Stas.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list

[alexandria-devel] [Patch]: Fix an example in the docstring of iota.

[Stas Boukarev]

An example in the docstring of iota was
(iota 4) = (0 1 2 3 4)
while it should've been
(iota 4) = (0 1 2 3).

From 3983fa28c3f0f66823cc1536cca34faa8fb16caf Mon Sep 17 00:00:00 2001
From: Stas Boukarev stass...@gmail.com
Date: Wed, 16 May 2012 00:53:20 +0400
Subject: [PATCH] Fix an example in the docstring of iota.

Was (iota 4) = (0 1 2 3 4), while should be (iota 4) = (0 1 2 3).
---
 numbers.lisp |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/numbers.lisp b/numbers.lisp
index 03430cc..2674582 100644
--- a/numbers.lisp
+++ b/numbers.lisp
@@ -48,7 +48,7 @@ and STEP. START defaults to 0 and STEP to 1.
 
 Examples:
 
-  (iota 4)  = (0 1 2 3 4)
+  (iota 4)  = (0 1 2 3)
   (iota 3 :start 1 :step 1.0)   = (1.0 2.0 3.0)
   (iota 3 :start -1 :step -1/2) = (-1 -3/2 -2)
 
-- 
1.7.9


-- 
With best regards, Stas.
___
alexandria-devel mailing list
alexandria-devel@common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/alexandria-devel

Re: [alexandria-devel] [Patch]: Fix an example in the docstring of iota.

[Stas Boukarev]

Stas Boukarev stass...@gmail.com writes:

 An example in the docstring of iota was
 (iota 4) = (0 1 2 3 4)
 while it should've been
 (iota 4) = (0 1 2 3).

Another problem seems to be with contagion when used with complex
numbers:
(alexandria:iota 5 :start 1 :step #c(1 2)) =
(1 #C(2 2) #C(3 4) #C(4 6) #C(5 8))

-- 
With best regards, Stas.

___
alexandria-devel mailing list
alexandria-devel@common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/alexandria-devel

Re: [cffi-devel] Next release of CFFI with cffi-libffi

[Stas Boukarev]

Luís Oliveira luis...@gmail.com writes:

 On Mon, Apr 30, 2012 at 11:02 PM, Max Mikhanosha m...@openchat.com wrote:
 This fixes it for me

 (defmethod foreign-type-size ((type symbol))
  (let ((*parse-bare-structs-as-pointers* nil))
    (foreign-type-size (parse-type type

 Thanks everyone for digging into this. While this fix does indeed fix
 the problem (nice catch!), using this special variable
 *PARSE-BARE-STRUCTS-AS-POINTERS* clearly turned out to be an
 overcomplicated and brittle approach.

 I've pushed a rewrite that should be much more robust.
Commonqt seems to work fine now.
When will there be a new release with this fix? So that it can be appear
in the next quicklisp update.

-- 
With best regards, Stas.

___
cffi-devel mailing list
cffi-devel@common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel

Re: [cffi-devel] Next release of CFFI with cffi-libffi

[Stas Boukarev]

Stelian Ionescu sione...@cddr.org writes:

 On Thu, 2012-04-19 at 14:46 +, Stas Boukarev wrote:
 Luís Oliveira luismbo at gmail.com writes:
 
  
  On Thu, Apr 19, 2012 at 2:50 PM, Stelian Ionescu sionescu at cddr.org 
 wrote:
   (with-foreign-object (p '(:struct timespec) 2)
(mem-aref p '(:struct timespec) 1))
  
   In order not to break existing code [...]
  
  Existing code will not have this (:struct foo) syntax because it was
  introduced by the libffi merge. (mem-aref p 'timespec 1) should
  exhibit backwards-compatible behaviour.
 Turns out, the problem is not with mem-aref, but with the mem-aref compile-
 macro. It binds *parse-bare-structs-as-pointers* to T, whereas mem-aref 
 function 
 doesn't, this affects the result of foreign-type-size.

 Actually it's mem-aref that should bind *parse-bare-structs-as-pointers*
 to T, so I pushed the fix

This breaks it.

(cffi:defcstruct foo
  (a :short)
  (b :short))

;; After binding *parse-bare-structs-as-pointers* to T in the mem-aref function:

(cffi:with-foreign-object
(var 'foo 20)
  (let ((type 'foo))
(cffi:mem-aref var type)))
;; new cffi = #.(SB-SYS:INT-SAP #X)
;; old cffi and new with a constant type return an expected address

;; Previous problems I originally described:

(cffi:with-foreign-object (var 'foo 2)
  (- (cffi-sys:pointer-address (cffi:mem-aref var 'foo 1))
 (cffi-sys:pointer-address (cffi:mem-aref var 'foo 0

;; old cffi = 4
;; new cffi = 8

;; With mem-aptr works as expected:

(cffi:with-foreign-object (var 'foo 2)
(- (cffi-sys:pointer-address (cffi:mem-aptr var 'foo 1))
   (cffi-sys:pointer-address (cffi:mem-aptr  var 'foo 0

;; new cffi = 4

-- 
With best regards, Stas.

___
cffi-devel mailing list
cffi-devel@common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel

Re: [cffi-devel] Next release of CFFI with cffi-libffi

[Stas Boukarev]

Stas Boukarev stass...@gmail.com writes:

 Stelian Ionescu sione...@cddr.org writes:

 On Thu, 2012-04-19 at 14:46 +, Stas Boukarev wrote:
 Luís Oliveira luismbo at gmail.com writes:
 
  
  On Thu, Apr 19, 2012 at 2:50 PM, Stelian Ionescu sionescu at cddr.org 
 wrote:
   (with-foreign-object (p '(:struct timespec) 2)
(mem-aref p '(:struct timespec) 1))
  
   In order not to break existing code [...]
  
  Existing code will not have this (:struct foo) syntax because it was
  introduced by the libffi merge. (mem-aref p 'timespec 1) should
  exhibit backwards-compatible behaviour.
 Turns out, the problem is not with mem-aref, but with the mem-aref compile-
 macro. It binds *parse-bare-structs-as-pointers* to T, whereas mem-aref 
 function 
 doesn't, this affects the result of foreign-type-size.

 Actually it's mem-aref that should bind *parse-bare-structs-as-pointers*
 to T, so I pushed the fix

 This breaks it.
And the same problem with *parse-bare-structs-as-pointers* being
different is also present in the setf macro for mem-aref.

-- 
With best regards, Stas.

___
cffi-devel mailing list
cffi-devel@common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel

Re: [pro] Sub-function free variable binding differences between Scheme and CL

[Stas Boukarev]

Burton Samograd burton.samog...@gmail.com writes:

 Hello,

 I am curently translating the logic circuit simulator code from SICP
 into Common Lisp and have run into a snag that I would like to ask
 about.

 The Scheme code is as follows from section 3.3.4 (page 223 of my
 hardcover edition):

 (define (and-gate a1 a2 output)
 (define (and-action-procedure)
 (let ((new-value
(locical-and (get-signal a1) (get-signal a2
  (after-delay and-gat-delay
   (lambda ()
   (set-signal! output new-value)
  (add-action! a1 and-action-procedure)
  (add-action! a2 and-action-procedure))

 The code basically binds the local function and-action-procedure into
 a list of functions in a1 and a2 which are then called by another
 routine later to perform the action when a value is set on the wire.

 My translated Common Lisp code is:

 (defun make-and-gate (a1 a2 output)
   (flet ((logical-and (a b)
(if (= a 1) b a))
  (and-action-proc ()
(let ((new-value (logical-and (get-signal a1) (get-signal a2
  (set-signal output new-value
 (add-action a1 #'and-action-proc)
 (add-action a2 #'and-action-proc)))
You should use LABELS instead of FLET, FLET doesn't make its definitions
available inside definitions so the call logical-and in and-action-proc
can't find logical-and.

And seriously, writing to the _pro_ mailing list to ask trivial questions?

-- 
With best regards, Stas.

___
pro mailing list
pro@common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/pro

Re: [pro] Sub-function free variable binding differences between Scheme and CL

[Stas Boukarev]

Burton Samograd burton.samog...@gmail.com writes:

 I apologize, my original code was using labels but I copied the one
 using flet for this question.  Please assume that I am using labels;
 the variable binding question still stands.

With labels, the code is right, that means either you're not telling
something else again, or the problem is in another place in the code.

-- 
With best regards, Stas.

___
pro mailing list
pro@common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/pro

Re: [Ecls-list] (require 'sockets) doesn't work

[Stas Boukarev]

Juan Jose Garcia-Ripoll juanjose.garciarip...@googlemail.com writes:

 What configuration and version (see first lines of ECL's prompt) are you
 using?
That was the latest git revision at the moment, with --enable-threads and 
--enable-unicode.

-- 
With best regards, Stas.

--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list

[Ecls-list] (require 'sockets) doesn't work

[Stas Boukarev]

 (require 'sockets)

;;; Loading #P/home/stas/lisp/impl/ecl/build/sockets.fas

Condition of type: SIMPLE-TYPE-ERROR
The value of ASDF::NAME is SOCKETS, which is not of type STRING.

While (require sockets) works.

-- 
With best regards, Stas.

--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
___
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list

Re: [Ecls-list] BUG: SEGMENTATION-VIOLATION in code with DEFTYPE unicode char

[Stas Boukarev]

Eric Marsden eric.mars...@free.fr writes:

 jgr == Juan Jose Garcia-Ripoll juanjose.garciarip...@googlemail.com 
 writes:

   jgr Here is the problem: char in Linux is signed char, while in OS X it
   jgr seems to default to unsigned char. I have changed ECL so that 
 BASE-CHAR
   jgr objects are unboxed using the explicit C type unsigned char to avoid 
 such
   jgr ambiguities. ASA I get to a non-firewalled computer I will upload the 
 fix.

   Thanks for the fix. Here is another bug which is possibly related
   (still on Linux/AMD64). 

 ,
 | ECL (Embeddable Common-Lisp) 11.1.1 
 (git:78442fa7bcb4ef486b704e16d0e7cefbd4bf7680)
 | Top level.
 |  (lambda (a) (declare (type (eql b) a)) (eql b a))
 | #bytecompiled-closure #bytecompiled-function 03cc6e10
 |  (compile nil *)
 | ;;; OPTIMIZE levels: Safety=2, Space=0, Speed=3, Debug=0
 | ;;;
 | ;;; End of Pass 1.
 | #compiled-function 03fc6980
 | NIL
 | NIL
 |  (funcall * b)
 | Condition of type: TYPE-ERROR
 | b is not of type (EQL b).
 `
I don't see how that's a bug, b isn't required to be EQL to b. It
can be, especially when coalesced by the compiler, but the reader
usually constructs a new string each time.

-- 
With best regards, Stas.

--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list

Re: [pro] why :key arguments?

[Stas Boukarev]

Tamas Papp tkp...@gmail.com writes:

 On Mon, 04 Jul 2011 11:39:39 +0200, Hans Hübner wrote:

 On Mon, Jul 4, 2011 at 11:31 AM, Tamas Papp
 tkp...@gmail.com wrote:
 Why do some CL library functions have :key arguments?
 [...]
 but it is a bit cumbersome.  I can make my code simpler by relying on
 calls like

 (quantiles (map 'vector key vector) quantiles)
 
 This not only conses a bit more, it also duplicates traversal efforts
 - The original list must be traversed, and the consed-up list of key
 values as well.  I think it is prudent that the CL library functions
 offer ways to reduce consing for cases where a bit is too much (and a
 bit can become a lot if a program operates on long lists).

 I understand this.  My main question is: why not do this with compiler 
 macros?  Is there any reason for this, other than historical?
Because it's not easy to do with compiler macros.

 Note that I am not complaining about the standard, I just want to learn 
 the reason for this design choice so that I can take it into account when 
 writing my own libraries.
I find (foo sequence :key #'key) much nicer than
(foo (map 'sequence #'key sequence))

-- 
With best regards, Stas.

___
pro mailing list
pro@common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/pro

Re: [pro] why :key arguments?

[Stas Boukarev]

Tamas Papp tkp...@gmail.com writes:

 On Mon, 04 Jul 2011 14:20:32 +0400, Stas Boukarev wrote:

 Tamas Papp tkp...@gmail.com writes:
 
 On Mon, 04 Jul 2011 11:39:39 +0200, Hans Hübner wrote:

 On Mon, Jul 4, 2011 at 11:31 AM, Tamas Papp tkp...@gmail.com wrote:
 Why do some CL library functions have :key arguments?
 [...]
 but it is a bit cumbersome.  I can make my code simpler by relying on
 calls like

 (quantiles (map 'vector key vector) quantiles)
 
 This not only conses a bit more, it also duplicates traversal
 efforts - The original list must be traversed, and the consed-up list
 of key values as well.  I think it is prudent that the CL library
 functions offer ways to reduce consing for cases where a bit is too
 much (and a bit can become a lot if a program operates on long
 lists).

 I understand this.  My main question is: why not do this with compiler
 macros?  Is there any reason for this, other than historical?
 Because it's not easy to do with compiler macros.

 Can you (or someone) please elaborate on that?  I have just started 
 reading up on compiler macros, and I don't understand why.

Suppose you have a function SUM,

(defun sum (list)
  (loop for i in list
sum i))

Now if you want to optimize (sum (map 'list KEY list)), you would
need to write an additional function.

(defun sum-key (list key)
  (loop for i in list
sum (funcall key i)))

And then you would need to write a compiler macro, which would match
(map 'list KEY sequence) and transform it into (sum-key sequence KEY),
which is not that hard, if that's only what you have. Now what if you
want it to work with (mapcar KEY list) too. It becomes more and more
cumbersome as it gets more general.

And now you need two functions, a clever compiler macro (perhaps using
some pattern matching library), and which may not do what the user
expects.

While you could have all that with just one function:

(defun sum (list key key)
  (loop for i in list
sum (if key
(funcall key i)
i)))
Other disadvantages of compiler-macros:

* They are not guaranteed to be expanded. Some implementations may
  ignore them.
* They can't be used with APPLY or FUNCALL.
* You can't compose them
  e.g. if you wanted to write
  (defun two-sum (list1 list2)
 (+ (sum list1) (sum list2)))
  You would need to write a second compiler macro. While with KEY
  keyword you could just pass it along.

-- 
With best regards, Stas.

___
pro mailing list
pro@common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/pro

Re: [Ecls-list] Problems with building

[Stas Boukarev]

Stas Boukarev stass...@gmail.com writes:

 The first problem I encounter when building the latest ECL is a stray
 reference to ecl_query_all_processes_status. That's easily fixable, and
 the attached patch does that.

 diff --git a/src/c/unixsys.d b/src/c/unixsys.d
 index ea46754..667de72 100755
 --- a/src/c/unixsys.d
 +++ b/src/c/unixsys.d
 @@ -294,7 +294,7 @@ ecl_waitpid(cl_object pid, cl_object wait)
  if (Null(flag)) {
  /* We come from the parallel thread, must lock */
  ECL_WITH_LOCK_BEGIN(env, cl_core.external_processes_lock) {
 -ecl_query_all_processes_status(0);
 +si_wait_for_all_processes(0);
  } ECL_WITH_LOCK_END(env, cl_core.external_processes_lock);
  return;
  }


 Next, I get:
 ;*** Lisp core booted 
 ECL (Embeddable Common Lisp)

 ;;;
 ;;; Welcome to bare.lsp. Let's bring this instance up!
 ;;;
 ;;;
 ;;; About to load lsp/load.lsp
 ;;; 
 ;;; Loading src:lsp;export.lsp
 ;;; Unhandled lisp initialization error
 ;;; Message:
 STACK-OVERFLOW
 ;;; Arguments:

 Internal or unrecoverable error in:

 Lisp initialization error.
Ok, I didn't notice that ecl_query_all_processes_status was inside
si_wait_for_all_processes definition, that's what causes
the stack-overflow.

-- 
With best regards, Stas.

--
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software 
be a part of the solution? Download the Intel(R) Manageability Checker 
today! http://p.sf.net/sfu/intel-dev2devmar
___
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list

Re: [postmodern-devel] sql-compile

[Stas Boukarev]

Haris fbogdano...@xnet.hr writes:

 What am I doing wrong here:

 (query (sql-compile `(:update 'kupci :set
  ,@(list 'ime (parameter ime))
  :where (:= 'id (parameter id)

 I get from hunchentoot log:

 Database error 42883: function parameter(unknown) does not exist
 No function matches the given name and argument types. You might need to add 
 explicit type casts.
 Query: UPDATE kupci SET ime = E'a' WHERE (id = parameter(E'id'))
Try
(query (sql-compile `(:update 'kupci :set
  ,@(list 'ime (parameter ime))
  :where (:= 'id ,(parameter id)
-- 
With Best Regards, Stas.

___
postmodern-devel mailing list
postmodern-devel@common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/postmodern-devel

Re: [postmodern-devel] Patch: {} syntax for arrays should be inside ''

[Stas Boukarev]

Stas Boukarev stass...@gmail.com writes:

 According  to
 http://www.postgresql.org/docs/current/static/arrays.html#ARRAYS-INPUT
 arrays should look like '{ val1 delim val2 delim ... }', but cl-postgres
 sends them as {val1 ...}, the attached patch corrects this.
Well, that was too soon, I forgot to attach the patch itself:
VC backend : Git
Working dir: ~/lisp/site/postmodern/
Branch : master
Remote : http://marijn.haverbeke.nl/git/postmodern
Stash  : Nothing stashed

 ./
 cl-postgres/
  *  edited  cl-postgres/sql-string.lisp


-- 
With Best Regards, Stas.
___
postmodern-devel mailing list
postmodern-devel@common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/postmodern-devel

Re: [postmodern-devel] Patch: {} syntax for arrays should be inside ''

[Stas Boukarev]

Stas Boukarev stass...@gmail.com writes:

 Stas Boukarev stass...@gmail.com writes:

 According  to
 http://www.postgresql.org/docs/current/static/arrays.html#ARRAYS-INPUT
 arrays should look like '{ val1 delim val2 delim ... }', but cl-postgres
 sends them as {val1 ...}, the attached patch corrects this.

Aw, now I hit C-x C-w in the wrong buffer, that's what you  get for
being in a hurry.
Sorry for the noise, here's the patch for real.
diff --git a/cl-postgres/sql-string.lisp b/cl-postgres/sql-string.lisp
index 7555cc9..d88 100644
--- a/cl-postgres/sql-string.lisp
+++ b/cl-postgres/sql-string.lisp
@@ -55,12 +55,12 @@ whether the string should be escaped before being put into a query.)
 (if (typep arg '(vector (unsigned-byte 8)))
 (values (escape-bytes arg) t)
 (with-output-to-string (out)
-  (write-char #\{ out)
+  (write-string '{ out)
   (loop :for sep :=  :then #\, :for x :across arg :do
  (princ sep out)
  (multiple-value-bind (string escape) (to-sql-string x)
(if escape (write-quoted string out) (write-string string out
-  (write-char #\} out
+  (write-string }' out
   (:method ((arg array))
 (with-output-to-string (out)
   (labels ((recur (dims off)
@@ -75,7 +75,9 @@ whether the string should be escaped before being put into a query.)
 (multiple-value-bind (string escape) (to-sql-string (row-major-aref arg i))
   (if escape (write-quoted string out) (write-string string out)
  (write-char #\} out)))
-  (recur (array-dimensions arg) 0
+(write-char #\' out)
+(recur (array-dimensions arg) 0)
+(write-char #\' out
   (:method ((arg integer))
 (princ-to-string arg))
   (:method ((arg float))

-- 
With Best Regards, Stas.
___
postmodern-devel mailing list
postmodern-devel@common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/postmodern-devel

Re: [pro] Learning Lisp the Bump Free Way

[Stas Boukarev]

Svante Carl v. Erichsen svante.v.erich...@web.de writes:

 Hi!

 I should call it string-conc, conc-string, or conc-string.  I should
 not expect from first sight that either, string+ or string*, would
 concatenate.  From those names, it also would seem surprising that
 they can take any sequences, not just strings, as arguments.

 I see the main merit of creating such a function of reduced generality
 in that you can pass it around as a simple #'string-conc instead of
 (lambda (rest sequences) (apply #'concatenate 'string sequences)).
Scheme has string-append.

-- 
With Best Regards, Stas.

___
pro mailing list
pro@common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/pro

Re: [Ecls-list] Cannot print object #SWANK-BACKEND package readably

[Stas Boukarev]

Anton Vodonosov avodono...@yandex.ru writes:

 Hello.
  
 Unfortunately deleting the ~/.slime directory doesn't help.
  
 Correction, the error happens not when I load swank-loader.lisp, but after 
 that, when I
 call swan-loader:init.
  
 Here is the backtrace:
  
 Backtrace:
    SWANK-LOADER::HANDLE-SWANK-LOAD-ERROR
    swank-loader::compile-files
    swank-loader::load-swank
    swank-loader:init
    si:bytecodes [Evaluation of: (swank-loader:init)]
    si:bytecodes [Evaluation of: (load start-swank.lisp)]
    si:bytecodes [Evaluation of: (si:top-level)]
  
 I also tried with elder version of slime - the same result.
This error means that you have *print-readably* set to T, while slime
shouldn't fail in such circumstances, in the meantime, set it to NIL.

-- 
With Best Regards, Stas.

--
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand 
malware threats, the impact they can have on your business, and how you 
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
___
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list

Re: [Ecls-list] Cannot print object #SWANK-BACKEND package readably

[Stas Boukarev]

Stas Boukarev stass...@gmail.com writes:

 Juan Jose Garcia-Ripoll juanjose.garciarip...@googlemail.com writes:

 What settings do you have? I do not get those errors in any of my systems?
 I can reproduce after doing (require 'bytecmp)
And its compile-file has WITH-STANDARD-IO-SYNTAX around WRITE, which
sets *print-readably* to T.

-- 
With Best Regards, Stas.

--
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires 
February 28th, so secure your free ArcSight Logger TODAY! 
http://p.sf.net/sfu/arcsight-sfd2d
___
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list

Re: [Ecls-list] Release ready

[Stas Boukarev]

Stas Boukarev stass...@gmail.com writes:

 Juan Jose Garcia-Ripoll juanjose.garciarip...@googlemail.com writes:

 Hi everybody,
 Regarding Stas Boukarev's problems with require-ing ASDF and compiling a
 test file that defines the ASDF package, I could not reproduce it in any
 system with a clean new copy of ECL.
 This is quite unfortunate, because this really is a show-stopper here, I
 can't load any .fas which weren't compiled in the current instance of
 ECL.

 Here is my further analyses:
 Consider the function
 ecl_make_package
 http://ecls.git.sourceforge.net/git/gitweb.cgi?p=ecls/ecl;a=blob;f=src/c/package.d;h=5939239084d30db5d484ce3ff8924a3ee64ef004;hb=HEAD#l195
 which is eventually called when loading the code I showed earlier.

 It calls
 x = find_pending_package(env, name, nicknames);

 which returns a package, because it finds it in env-packages_to_be_created 
 (which, I
 presume, is set up by LOAD), so that means that if (Null(x)) { ... } is
 not executed, and the variable `other' isn't set to anything.
 Next, it iterates over nicknames, which it has none, and `other' is still
 untouched.
 And finally, it does
 if (!Null(other))

 but the variable `other' wasn't ever initialized, and when I insert a print
 statement there, it shows #illegal pointer bf9c2d38, which isn't null,
 and it's eventually passed to CEpackage_error, which then
 complains not a lisp data object.
And the patch which fixes the problem for me.
diff --git a/src/c/package.d b/src/c/package.d
index 5939239..88d5957 100644
--- a/src/c/package.d
+++ b/src/c/package.d
@@ -195,7 +195,7 @@ cl_object
 ecl_make_package(cl_object name, cl_object nicknames, cl_object use_list)
 {
 const cl_env_ptr env = ecl_process_env();
-	cl_object x, l, other;
+	cl_object x, l, other = Cnil;
 
 /* Type checking, coercions, and the like, happen before we
  * acquire the lock */

-- 
With Best Regards, Stas.
--
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand 
malware threats, the impact they can have on your business, and how you 
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl___
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list

Re: [Ecls-list] Release ready

[Stas Boukarev]

Juan Jose Garcia-Ripoll juanjose.garciarip...@googlemail.com writes:

 I had to fix a number of bugs that were submitted during the last days.
 Unless somebody complains very loud (please, no! :-) I will tag and upload
 the 11.1.1 release this weekend.

When doing (require 'asdf)
I get
;;; Loading #P/usr/local/lib/ecl-11.1.1/asdf.fas

Internal or unrecoverable error in:
not a lisp data object
  [2: No such file or directory]

;;; ECL C Backtrace
;;; /usr/local/lib/libecl.so.11.1(si_dump_c_backtrace+0x2f) [0xb77de577]
;;; /usr/local/lib/libecl.so.11.1(ecl_internal_error+0x8c) [0xb77d180d]
;;; /usr/local/lib/libecl.so.11.1(cl_class_of+0x216) [0xb77bcc4e]
;;; /usr/local/lib/libecl.so.11.1(+0xa78d6) [0xb77528d6]
;;; /usr/local/lib/libecl.so.11.1(APPLY_fixed+0x6a) [0xb78177eb]
;;; /usr/local/lib/libecl.so.11.1(ecl_apply_from_stack_frame+0xc6) [0xb77afed0]
;;; /usr/local/lib/libecl.so.11.1(cl_funcall+0xc5) [0xb77b01bb]
;;; /usr/local/lib/libecl.so.11.1(+0x113156) [0xb77be156]
;;; /usr/local/lib/libecl.so.11.1(_ecl_standard_dispatch+0x240) [0xb77be403]
;;; /usr/local/lib/libecl.so.11.1(ecl_apply_from_stack_frame+0x12d) [0xb77aff37]
;;; /usr/local/lib/libecl.so.11.1(cl_apply+0x1f4) [0xb77b03bd]
;;; /usr/local/lib/libecl.so.11.1(+0xb42e1) [0xb775f2e1]
;;; /usr/local/lib/libecl.so.11.1(APPLY+0x1b3) [0xb780dc43]
;;; /usr/local/lib/libecl.so.11.1(ecl_apply_from_stack_frame+0xe4) [0xb77afeee]
;;; /usr/local/lib/libecl.so.11.1(cl_apply+0x8d) [0xb77b0256]
;;; /usr/local/lib/libecl.so.11.1(+0xadfd2) [0xb7758fd2]
;;; /usr/local/lib/libecl.so.11.1(+0xae178) [0xb7759178]
;;; /usr/local/lib/libecl.so.11.1(APPLY+0x79) [0xb780db09]
;;; /usr/local/lib/libecl.so.11.1(ecl_apply_from_stack_frame+0x102) [0xb77aff0c]
;;; /usr/local/lib/libecl.so.11.1(cl_funcall+0xc5) [0xb77b01bb]
;;; /usr/local/lib/libecl.so.11.1(_ecl_standard_dispatch+0x285) [0xb77be448]
;;; /usr/local/lib/libecl.so.11.1(ecl_apply_from_stack_frame+0x12d) [0xb77aff37]
;;; /usr/local/lib/libecl.so.11.1(cl_apply+0x1f4) [0xb77b03bd]
;;; /usr/local/lib/libecl.so.11.1(+0xe1c25) [0xb778cc25]
;;; /usr/local/lib/libecl.so.11.1(APPLY+0x1b3) [0xb780dc43]
;;; /usr/local/lib/libecl.so.11.1(ecl_apply_from_stack_frame+0xe4) [0xb77afeee]
;;; /usr/local/lib/libecl.so.11.1(cl_apply+0x1f4) [0xb77b03bd]
;;; /usr/local/lib/libecl.so.11.1(+0xe23bc) [0xb778d3bc]
;;; /usr/local/lib/libecl.so.11.1(+0xe47b3) [0xb778f7b3]
;;; /usr/local/lib/libecl.so.11.1(APPLY_fixed+0x92) [0xb7817813]
;;; /usr/local/lib/libecl.so.11.1(ecl_apply_from_stack_frame+0xc6) [0xb77afed0]
;;; /usr/local/lib/libecl.so.11.1(cl_funcall+0xc5) [0xb77b01bb]

-- 
With Best Regards, Stas.

--
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand 
malware threats, the impact they can have on your business, and how you 
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
___
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list

Re: [Ecls-list] Release ready

[Stas Boukarev]

Juan Jose Garcia-Ripoll juanjose.garciarip...@googlemail.com writes:

 Configuration flags? Platform?

Interestingly, the following succeeds:
 (make-package ASDF)

#ASDF package
 (require 'asdf)

;;; Loading #P/usr/local/lib/ecl-11.1.1/asdf.fas
;;; Loading #P/usr/local/lib/ecl-11.1.1/cmp.fas
(ASDF CMP)


-- 
With Best Regards, Stas.

--
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand 
malware threats, the impact they can have on your business, and how you 
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
___
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list

Re: [Ecls-list] Release ready

[Stas Boukarev]

Juan Jose Garcia-Ripoll juanjose.garciarip...@googlemail.com writes:

 Configuration flags? Platform?
Digging further:

Given file
;;;
(eval-when (:compile-toplevel :load-toplevel :execute)
  (unless (find-package :asdf)
(make-package :asdf :use '(:cl

(in-package :asdf)
(print 'foo)
;;;

Start fresh ecl:
(compile-file foo.lisp)

Exit ecl, start it again:
(load foo.fas) = crash

I guess it has to do with discrepancies between compile-time and load-time
packages, and interning FOO causes problems.

-- 
With Best Regards, Stas.

--
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand 
malware threats, the impact they can have on your business, and how you 
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
___
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list

[drakma-devel] [Patch]: better file-names when sending multipart/form-data from streams.

[Stas Boukarev]

The attached patch does two things:
* :filename option takes precedence of automatically determined names
 (it was the case previously only for pathnames, and not for streams or 
functions).
* if stream is a file-stream, which means it's a pathname designator,
use file-namestring to get the filename.
--- old-drakma/request.lisp	2010-12-26 16:45:30.356179246 +0300
+++ new-drakma/request.lisp	2010-12-26 16:45:30.356179246 +0300
@@ -112,10 +112,13 @@
   (first value)
   (not (stringp (first value
  (let* ((file-source (first value))
-(filename (or (if (functionp file-source) user-closure)
-  (if (streamp file-source) user-stream)
-  (getf (rest value) :filename)
-  (file-namestring file-source)))
+(filename (or (getf (rest value) :filename)
+  (etypecase file-source
+(function user-closure)
+(file-stream (or (file-namestring file-source)
+ user-stream))
+(stream user-stream)
+(pathname (file-namestring file-source)
 (content-type (or (getf (rest value) :content-type)
   application/octet-stream)))
(format stream ; filename=\~A\ filename)

-- 
With Best Regards, Stas.
___
drakma-devel mailing list
drakma-devel@common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/drakma-devel

[Ecls-list] multiple-value-bind strange behaviour

[Stas Boukarev]

Consider the following file:
(defun foo ())

(defun location (function)
  (multiple-value-bind (file pos) (ext:compiled-function-file function)
(list file pos)))

Load it:
 (load (compile-file foo))
 (location #'foo)
(foo.lisp NIL)
 (ext:compiled-function-file #'foo)   
foo.lisp
0

-- 
With Best Regards, Stas.

--
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
___
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list

[Bug 597829] Re: sbcl install and execution give Illegal instruction error

[Stas Boukarev]

** Changed in: sbcl
   Status: New = Invalid

-- 
sbcl install and execution give Illegal instruction error
https://bugs.launchpad.net/bugs/597829
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Re: [drakma-devel] :close nil

[Stas Boukarev]

On 8/26/08, Edi Weitz [EMAIL PROTECTED] wrote:
 On Tue, 26 Aug 2008 09:28:04 +0400, Stas Boukarev [EMAIL PROTECTED] wrote:

   It still spends 6 second in FLEXI-STREAMS::READ-SEQUENCE*


 Seems there was another thinko in FLEXI-STREAMS.  Could you try with
  1.0.7 again?

Still the same... I also noticed that it's fast if it encounters 404 error.

-- 
With Best Regards, Stas.
___
drakma-devel mailing list
drakma-devel@common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/drakma-devel

Re: [drakma-devel] :close nil

[Stas Boukarev]

On 8/26/08, Edi Weitz [EMAIL PROTECTED] wrote:
 On Mon, 25 Aug 2008 16:52:03 +0400, Stas Boukarev [EMAIL PROTECTED] wrote:

   When I call http-request with :close nil argument it takes 6 seconds
   more


 Please try with FLEXI-STREAMS 1.0.6, that should hopefully fix this.

It still spends 6 second in FLEXI-STREAMS::READ-SEQUENCE*


-- 
With Best Regards, Stas.
___
drakma-devel mailing list
drakma-devel@common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/drakma-devel

[Orgmode] Numbered lists

[Stas Boukarev]

When I put `1.' on the first line of a blank file, and then press
M-return I get the following:
1.
1.
2.
3.

Is it a supposed result?

Emacs and org-mode from cvs and git respectively.

-- 
With Best Regards, Stas.


___
Emacs-orgmode mailing list
Remember: use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Bug#475170: [axiom] Unuseable on amd64 - fails to start

[Stas Boukarev]

I confirm this.

-- 
With Best Regards, Stas.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

[Bug 132939] Re: [gutsy] Suspend does not work from GDM login screen

[Stas Boukarev]

Yes, it is needed for hardy's gdm. Source code of development version of
gdm was changed so deeply, I can't find corresponding code.

-- 
[gutsy] Suspend does not work from GDM login screen
https://bugs.launchpad.net/bugs/132939
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is a bug assignee.

-- 
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs

[Bug 132939] Re: [gutsy] Suspend does not work from GDM login screen

[Stas Boukarev]

Yes, it is needed for hardy's gdm. Source code of development version of
gdm was changed so deeply, I can't find corresponding code.

-- 
[gutsy] Suspend does not work from GDM login screen
https://bugs.launchpad.net/bugs/132939
You received this bug notification because you are a member of Ubuntu
Bugs, which is the bug contact for Ubuntu.

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 132939] Re: [gutsy] Suspend does not work from GDM login screen

[Stas Boukarev]

I have fixed this with the following patch

** Attachment added: gdm suspend patch
   http://launchpadlibrarian.net/11039850/suspend.patch

-- 
[gutsy] Suspend does not work from GDM login screen
https://bugs.launchpad.net/bugs/132939
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is a bug assignee.

-- 
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs

[Bug 132939] Re: [gutsy] Suspend does not work from GDM login screen

[Stas Boukarev]

I have fixed this with the following patch

** Attachment added: gdm suspend patch
   http://launchpadlibrarian.net/11039850/suspend.patch

-- 
[gutsy] Suspend does not work from GDM login screen
https://bugs.launchpad.net/bugs/132939
You received this bug notification because you are a member of Ubuntu
Bugs, which is the bug contact for Ubuntu.

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Problems with progress on large files

[Stas Boukarev]

Wget aborts on huge files:

$ wget ftp://ftp.fsn.hu/testfiles/128T

get: progress.c:965: create_image: Assertion `p - bp-buffer =
bp-width' failed.
Aborted

But wget -q ftp://ftp.fsn.hu/testfiles/128T works fine.

I tried Wget 1.10+devel from svn trunk branch, Revision 2202.
Compiled with gcc 3.4.6 on 32-bit GNU/Linux system with glibc-2.3.6.

$ uname -a
Linux slack 2.6.19.2 #1 Thu Jan 11 11:40:47 MSK 2007 i686 pentium4 i386
GNU/Linux

-- 
With Best Regards, Stas.
All You Need Is Love!
Homo sum et nihil humani a me alienum puto.

Addition to problems with progress on large files

[Stas Boukarev]

I've noticed problem is related with ETA calculating
and on systems with high bandwidth it may not fail.

It better to test something like
$ wget --limit-rate=1024 ftp://ftp.fsn.hu/testfiles/128T

-- 
With Best Regards, Stas.
All You Need Is Love!
Homo sum et nihil humani a me alienum puto.