On Tue, Aug 17, 2010 at 6:20 PM, Stas Boukarev <stassats@...> wrote:
> Martin Cracauer <cracauer@...> writes:
>
>> I have streams (from fds originally) that I write strings to. The
>> profile has a lot of utf-8 related functions pop up, and I think it
>> keeps up with the position in the stream although there is no reason
>> to. The strings are all braindead 7-bit ASCII that as far as I'm
>> concerned could just be dumped into Unix write(2), although buffering
>> without converting would be preferable.
>>
>> Any idea how to get this back to a plain bytesucker stream?
>>
> Open it with :element-type '(unsigned-byte 8)?
Or :external-format :ascii ?
-- Alastair Bridgewater

Martin Cracauer <cracauer@...> writes:
> I have streams (from fds originally) that I write strings to. The
> profile has a lot of utf-8 related functions pop up, and I think it
> keeps up with the position in the stream although there is no reason
> to. The strings are all braindead 7-bit ASCII that as far as I'm
> concerned could just be dumped into Unix write(2), although buffering
> without converting would be preferable.
>
> Any idea how to get this back to a plain bytesucker stream?
>
Open it with :element-type '(unsigned-byte 8)?
--
With Best Regards, Stas.

Hi, guys.
I'm a developer who likes to learn more about SBCL runtime internals.
Being on very early stages of new OS development I need to understand is
it worthy to build OS on top of lispy runtime. I see lisp-like language
as a main system language (like C language in Unix-like systems), so I
need to know if replacing ordinal stack / register virtual machine (I
prefer a managed environment) by a lisp runtime virtual machine will
make programs run more efficient?
I will describe my view. Let's imagine lisp runtime operating with
machine size numbers (arbitrary size numbers are on a layer above),
explicitly supporting arrays, different VOPs, etc. On the layer above
there is a main lispy language compiler. The question is the following:
will the lisp runtime playing the part of a virtual machine be worth to
base on (supposing that main language compiler will be able to pass
intermediate code to it more preserving original semantics for
optimization purposes compared to ordinal stack / register virtual
machine)?
My substantial lack of knowledge about modern lisp compilation forces me
to ask another, maybe stupid question. Is the lisp compilers at general
embed a minimal interpreter to compiled code? I mean, when I define a
function with some work flow (conditions, recursion, etc) is it
interpreted on the low level (of course, with some VOP blocks of machine
code inlined and some optimization transformations applied)? Under
interpretation I understand the process that flow in lisp processors
(chips), well described in the following white paper: “Design of
LISP-Based Processors or, SCHEME: A Dielectric LISP or, Finit Memories
Considered Harmful or, LAMBDA: Ultimate Opcode” by Guy Lewis Steele Jr.
and Gerald Jay Sussman.
Thanks in advance.

Nikodemus wrote:
> On 17 August 2010 16:05, Alastair Bridgewater
> <alastair.bridgewater@...> wrote:
>
>> Please don't limit it to those features "intended for users", even if
>> you only document it for such features. Â Being able to add (or
>> remove), say, :unwind-to-frame-and-call-vop or similar
>> backend-specific features at build time without hacking either c-t-f
>> or make-config would be convenient when doing backend hacking or
>> testing.
>
> Good point.
>
> Maybe "user-friendly" features get named options, but you could also
> add an arbitrary number of --enable=feature-name
> --disable=feature-name options?
>
> ...or maybe just the latter, for simplicity's sake?
For an autoconf feel, I would recommend the standard --enable-feature and
--disable-feature flags (or --with-tool and --without-tool). But then
there's a big mapping that needs to be maintained.
For a lispy feel, maybe we could put the keywords directly on the command
line? All keywords could be automatically collected and inserted into the
local config list. AFAICT, most keywords are command-line compatible.
e.g.
./make.sh :unwind-to-frame-and-call-vop
- Daniel

On 17 August 2010 19:20, Gabriel Dos Reis <gdr@...> wrote:
> I agree that simplicity should prevail.
> Unless there is a serious need for autoconf like
> configure, I would suggest to stick with simple usable
> options for make.sh.
> If it starts doing autoconf stuff, then there should be
> a separate configure script.
To avoid confusion:
I am strongly opposed to autoconf. It's not on the table as far as I
am concerned.
What I'm cool with is to a separate ./configure script, allowing
options to persist across make.sh invocations. I don't feel strongly
about it either way.
Cheers,
-- Nikodemus

2010/8/17 Nikodemus Siivola <nikodemus@...>:
> 2010/8/17 Gábor Melis <mega@...>:
>
>>> Of course we could have a separate ./configure step and save the
>>> options for future builds.
>>
>> As much as I'm a fan of autoconf (very little) there is some value in
>> being superficially similar to it, if only for sake of familiarity. As
>> to whether to persist options, if it's an exclusive choice then I vote
>> for persisting.
>
> Unless we separate out ./configure (or ./make-config.sh or whatever),
> persisting options seems confusing to me.
>
> A trivial non-confusing option for persisting without ./configure
> would be to add
>
> echo $0 $* >> make.log
>
> to make.sh, and have remake.sh along the lines of
>
> #!/bin/sh
> sh `tail -n1 make.log`
>
> ...not really sure if I'm serious or not.
>
I agree that simplicity should prevail.
Unless there is a serious need for autoconf like
configure, I would suggest to stick with simple usable
options for make.sh.
If it starts doing autoconf stuff, then there should be
a separate configure script.

On 17 August 2010 17:33, Roman Marynchak <roman.marynchak@...> wrote:
> Thank you for the detailed response:) I do agree with you about all points
> except the issues confirmation policy. The confirmation policy which you
> have just described seems to be used at this time (people submit new tickets
> and wait until these will be confirmed by the team members). I suggest to
> try a slightly different approach:
>
> 1. One who have created the ticket can only mark it 'Invaild', but cannot
> confirm the issue (to avoid the single-person-visible-only issues).
> 2. Anyone can confirm tickets from other people in case he or she has
> reproduced the same issue (and yes, we believe the people to be fair, this
> is obvious).
> 3. Only committers can mark the tickets from other people 'invalid'.
Launchpad doesn't have customizable permissions, so we can't really
prevent people from marking things "confirmed", so...
Only two statuses are restricted: Triaged and Won't Fix -- only bug
supervisor for the project (that is, for SBCL anyone in the
sbcl-hackers group) can use them.
Possibly we should start using Triaged as well. (And migrating most of
current Confirmed bugs to Triaged.)
> I do not think that there will be more fixed bugs per month with this
> approach, but it makes the tickets management to be more flexible.
It's all about convenience. I mostly established our "launchpad style"
and I did it in the way that seemed most convenient for me (and
hopefully other committers.)
However, if there are tasks other people are willing and able to do,
and the way we use Launchpad is slowing them down, then it's an issue
we should fix.
Cheers,
-- Nikodemus

Thank you for the detailed response:) I do agree with you about all points
except the issues confirmation policy. The confirmation policy which you
have just described seems to be used at this time (people submit new tickets
and wait until these will be confirmed by the team members). I suggest to
try a slightly different approach:
1. One who have created the ticket can only mark it 'Invaild', but cannot
confirm the issue (to avoid the single-person-visible-only issues).
2. Anyone can confirm tickets from other people in case he or she has
reproduced the same issue (and yes, we believe the people to be fair, this
is obvious).
3. Only committers can mark the tickets from other people 'invalid'.
I do not think that there will be more fixed bugs per month with this
approach, but it makes the tickets management to be more flexible.
Best Regards,
Roman
2010/8/17 Nikodemus Siivola <nikodemus@...>
> On 29 May 2010 23:45, Roman Marynchak <roman.marynchak@...> wrote:
>
> > This is a question to SBCL maintainers. I probably had to ask it before
> > nominating my patches for release in Launchpad, but anyway it is better
> to
> > ask later than to ask never:)
>
> ...and better to answer late than never... :)
>
> > The question is: what should I do after I have provided the patch and
> > counted all notes about the problems with the patch? Should I mark the
> issue
> > 'In progress', assign it to me and nominate it for release? Or I should
> stop
> > after the final patch is provided, and do not touch the ticket anymore?
> Do
> > we have any rules about this?
>
> I think I would prefer:
>
> 1. Mark the issue In progress, and assign it to yourself.
>
> 2. Once it's done, tag it for review. We don't currently use the
> release nomination stuff, and even if we did, it would be for "this
> bug should be fixed for release X", not "this specific fix was
> approved".
>
> > Also, what is the issues confirmation policy? Should they be confirmed by
> > maintainers only, or other registered in Launchpad people also may
> confirm
> > an issue?
>
> I think my general preference is that only committers should mark
> stuff confirmed -- that way people whose issues have been confirmed
> can know that at least someone on the team has seen the bug.
>
> That said, comments from non-committers about bugs ("I can replicate
> this bug on FooBSD 13 SPARC, SBCL from today's CVS.") are _extremely_
> welcome.
>
> > I am asking this to avoid confusions during Launchpad usage. It would be
> > good to have the 'official' rules about SBCL Launchpad site stated
> somewhere
> > and to obey them.
>
> Very true. For the first 6 month or year of our Launchpad usage almost
> everyone who used it was a committer, or sufficiently telepathic that
> things worked reasonably well without thinking about it too much --
> but writing a nice set of guidelines is probably in order now.
>
> Cheers,
>
> -- Nikodemus
>

2010/8/17 Gábor Melis <mega@...>:
>> Of course we could have a separate ./configure step and save the
>> options for future builds.
>
> As much as I'm a fan of autoconf (very little) there is some value in
> being superficially similar to it, if only for sake of familiarity. As
> to whether to persist options, if it's an exclusive choice then I vote
> for persisting.
Unless we separate out ./configure (or ./make-config.sh or whatever),
persisting options seems confusing to me.
A trivial non-confusing option for persisting without ./configure
would be to add
echo $0 $* >> make.log
to make.sh, and have remake.sh along the lines of
#!/bin/sh
sh `tail -n1 make.log`
...not really sure if I'm serious or not.
Cheers,
-- Nikodemus

On 29 May 2010 23:45, Roman Marynchak <roman.marynchak@...> wrote:
> This is a question to SBCL maintainers. I probably had to ask it before
> nominating my patches for release in Launchpad, but anyway it is better to
> ask later than to ask never:)
...and better to answer late than never... :)
> The question is: what should I do after I have provided the patch and
> counted all notes about the problems with the patch? Should I mark the issue
> 'In progress', assign it to me and nominate it for release? Or I should stop
> after the final patch is provided, and do not touch the ticket anymore? Do
> we have any rules about this?
I think I would prefer:
1. Mark the issue In progress, and assign it to yourself.
2. Once it's done, tag it for review. We don't currently use the
release nomination stuff, and even if we did, it would be for "this
bug should be fixed for release X", not "this specific fix was
approved".
> Also, what is the issues confirmation policy? Should they be confirmed by
> maintainers only, or other registered in Launchpad people also may confirm
> an issue?
I think my general preference is that only committers should mark
stuff confirmed -- that way people whose issues have been confirmed
can know that at least someone on the team has seen the bug.
That said, comments from non-committers about bugs ("I can replicate
this bug on FooBSD 13 SPARC, SBCL from today's CVS.") are _extremely_
welcome.
> I am asking this to avoid confusions during Launchpad usage. It would be
> good to have the 'official' rules about SBCL Launchpad site stated somewhere
> and to obey them.
Very true. For the first 6 month or year of our Launchpad usage almost
everyone who used it was a committer, or sufficiently telepathic that
things worked reasonably well without thinking about it too much --
but writing a nice set of guidelines is probably in order now.
Cheers,
-- Nikodemus

2010/8/17 Nikodemus Siivola <nikodemus@...>:
> 2010/8/17 Gábor Melis <mega@...>:
>> On Tue, Aug 17, 2010 at 2:48 PM, Nikodemus Siivola
>> <nikodemus@...> wrote:
>>> Now that make.sh has command-line arguments, I'm tempted to add
>>> options for "intended for users" *features* so that
>>> customize-target-features.lisp is not needed anymore for casual
>>> builders.
>>>
>>> Any thoughts on this?
>>
>> Would those options stick around and affect subsequent builds a'la
>> autoconf and c-t-f.lisp?
>
> I'm thinking no.
>
> ./make.sh --threads=yes --docstrings=no
>
> would build without docstrings and with threads, but plain ./make.sh
> after that would do whatever the default was.
>
> Of course we could have a separate ./configure step and save the
> options for future builds.
As much as I'm a fan of autoconf (very little) there is some value in
being superficially similar to it, if only for sake of familiarity. As
to whether to persist options, if it's an exclusive choice then I vote
for persisting.

On 17 August 2010 16:05, Alastair Bridgewater
<alastair.bridgewater@...> wrote:
> Please don't limit it to those features "intended for users", even if
> you only document it for such features. Being able to add (or
> remove), say, :unwind-to-frame-and-call-vop or similar
> backend-specific features at build time without hacking either c-t-f
> or make-config would be convenient when doing backend hacking or
> testing.
Good point.
Maybe "user-friendly" features get named options, but you could also
add an arbitrary number of --enable=feature-name
--disable=feature-name options?
...or maybe just the latter, for simplicity's sake?
Cheers,
-- Nikodemus

2010/8/17 Gábor Melis <mega@...>:
> On Tue, Aug 17, 2010 at 2:48 PM, Nikodemus Siivola
> <nikodemus@...> wrote:
>> Now that make.sh has command-line arguments, I'm tempted to add
>> options for "intended for users" *features* so that
>> customize-target-features.lisp is not needed anymore for casual
>> builders.
>>
>> Any thoughts on this?
>
> Would those options stick around and affect subsequent builds a'la
> autoconf and c-t-f.lisp?
I'm thinking no.
./make.sh --threads=yes --docstrings=no
would build without docstrings and with threads, but plain ./make.sh
after that would do whatever the default was.
Of course we could have a separate ./configure step and save the
options for future builds.
Cheers,
-- Nikodemus

On Tue, Aug 17, 2010 at 8:48 AM, Nikodemus Siivola
<nikodemus@...> wrote:
> Now that make.sh has command-line arguments, I'm tempted to add
> options for "intended for users" *features* so that
> customize-target-features.lisp is not needed anymore for casual
> builders.
>
> Any thoughts on this?
Please don't limit it to those features "intended for users", even if
you only document it for such features. Being able to add (or
remove), say, :unwind-to-frame-and-call-vop or similar
backend-specific features at build time without hacking either c-t-f
or make-config would be convenient when doing backend hacking or
testing.
-- Alastair Bridgewater

On Tue, Aug 17, 2010 at 2:48 PM, Nikodemus Siivola
<nikodemus@...> wrote:
> Now that make.sh has command-line arguments, I'm tempted to add
> options for "intended for users" *features* so that
> customize-target-features.lisp is not needed anymore for casual
> builders.
>
> Any thoughts on this?
Would those options stick around and affect subsequent builds a'la
autoconf and c-t-f.lisp?

Now that make.sh has command-line arguments, I'm tempted to add
options for "intended for users" *features* so that
customize-target-features.lisp is not needed anymore for casual
builders.
Any thoughts on this?
Cheers,
-- Nikodemus