Towards Pharo 1.0

Hi all,

Marcus, Stef and I have been meeting today and we discussed how to  
proceed for the first release (version 1.0). On the issue tracker we  
tagged issues that we think should be fixed with "milestone-1.0". See  
the following list:

http://code.google.com/p/pharo/issues/list?q=milestone:1.0

If we missed something critical, please let us know.



Furthermore, we updated the high-level milestones list that is on the  
wiki (http://code.google.com/p/pharo/wiki/Milestones). The most  
notable change is that we removed Alien FFI and moved it to milestone  
1.1.

FUNCTIONAL REQUIREMENTS
        • (x) Integrate Polymorph
        • (x) Integrate TrueType?
        • (x) Refactor Traits API
        • ( ) default in-image font(s)
        • ( ) Main EToys removal, reorganize MorphicExtras?-
        • ( ) Package management system with stable and unstable distributions
        • ( ) Remove SqueakMap? and Installer from core

NON-FUNCTIONAL REQUIREMENTS
        • (x) First consistent version of the website
        • ( ) All tests green
        • ( ) Clean up package and class category organization
        • ( ) License clean (check OLPC changes)
        • ( ) Pharo one-click image (including developer tools,  
GettingStarted information, screenshots, ...)
        • ( ) New sources file

INFRASTRUCTURE
        • (x) Increase efficiency of producing new updates
        • ( ) Prepare second update stream to maintain released version


Cheers,
Adrian

___________________
http://www.adrian-lienhard.ch/
_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Adrian Lienhard wrote:
I would vote for the full unicode support. I'm currently battling with
ParagraphEditor and friends (don't ask...), but I think we are getting
there. I will look at Andreas fixes in that area and integrate them into
my changes as well.

Michael

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

On 23.02.2009, at 20:45, Adrian Lienhard wrote:

> Hi all,
>
> Marcus, Stef and I have been meeting today and we discussed how to
> proceed for the first release (version 1.0).


One note to everyone who submitted a bugreport... no, note at the end of
the mail. First a story.

In Squeak, people submitted lots of improvements and bugs, first with  
the funky [TAGS] to the
list, later  via the bugtracker. But then, a curious thing happened:  
they never, ever, looked
at that bug-report again. Maybe the image side code changed, and the  
submission
needed a trivial change so that the changeset could be loaded. Or  
there was some
question posted by a harvester. Or after 1000 applied changesets,  
there might be
the possibility that a bug is already fixed. Kind of obvious, that the  
submitter
of a report can help a lot in these situations. But they don't. I have  
*no clue* why.

In the end, I closed lots (really lots!) of entries in Squeak over the  
years
after a question to the original submitter was not anwered after 1  
year(!) of waiting.

I really wonder what the problem was... the submitter cared a lot when  
submitting the bug
or improvement in the first place. But then, just answering a question  
or re-do a changeset
(maybe 30min of work for the original author) was too much... a mystery.

Thus: As we are nearing 1.0, I kindly ask everyone who submitted  
something to look at the
report. Maybe you can make it easier to have it integrated? e.g.  
exactly describing the action
needed is better than making it a riddle (some people think that it is  
a sign of intelligence
to not give the solution to a problem after describing the cause). A  
changeset (or mcz) is
the best. Even for a one-line triviality.

You reported a bug half a year ago? Try to recreate it and add a  
comment: This is still a problem
in #10243 and the way I re-created the problem is this.

In the end, the question is: If you don't care, why should we?

        Marcus

-
Marcus Denker  --  [hidden email]
http://www.marcusdenker.de


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Marcus Denker wrote:

> of a report can help a lot in these situations. But they don't. I have  
> *no clue* why.

First a mea culpa, I'm one of those on occasions...

One problem is (was?) notification.

When you signed up for notifications from the Squeak bug tracker you got
drowned in emails to the point where I just filtered them to the trash
unread, thus never seeing any updates even on my own reports.

If there is a reasonably easy way to be only notified when "interesting"
bug reports are changed (or set up email filters), that would go a long
way IMHO.

Michael

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Notification seems to work very well with Google Code. I think, by  
default you get mail notifications for issues that you created or that  
you are in CC or that you starred (by clicking on the star). You can  
change this if you log in and go to Settings.

I also subscribed to the RSS feed to monitor all changes to issues and  
wiki pages.

Cheers,
Adrian

On Feb 23, 2009, at 21:48 , Michael Rueger wrote:


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

What happens with the requirements () which are not marked with (x) to be included in milestone version 1.0?  Or are the (x) mandatory release requirements and () optional?

If the "default in-image font(s)" requirement is possible it may be a good idea since it is all part of the first impression.  Anyhow, great job so far is all I can say :)

On 23.02.2009, at 23:02, Geert wrote:

>
> What happens with the requirements () which are not marked with (x)  
> to be
> included in milestone version 1.0?  Or are the (x) mandatory release
> requirements and () optional?
>

no, (x) is done, () will be done :-)

> If the "default in-image font(s)" requirement is possible it may be  
> a good
> idea since it is all part of the first impression.  Anyhow, great  
> job so far
> is all I can say :)

thanks!

--
Marcus Denker  --  [hidden email]
http://www.marcusdenker.de


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Both are "mandatory":

( ) means not done yet
(x) means completed

For some reason, [ ] has some special meaning with the wiki syntax IIRC

Cheers,
Adrian


On Feb 23, 2009, at 23:02 , Geert wrote:


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> • ( ) New sources file

I do not get this one.

> • ( ) Prepare second update stream to maintain released version


Why would you need a second update stream? PharoInbox2 ?

Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.






_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Milestone 3 includes

• closures (may be with the changes of mathieu with a new image format)

Didn't we pickup Eliot's recent closure work?  If so, how do the two relate?

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

On 24.02.2009, at 00:40, David Pennell wrote:

> Milestone 3 includes
> • closures (may be with the changes of mathieu with a new image  
> format)
> Didn't we pickup Eliot's recent closure work?

Yes. (so either this is an error or for confusing the enemy ;-)

> If so, how do the two relate?

Very similar.

        Marcus


--
Marcus Denker  --  [hidden email]
http://www.marcusdenker.de


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

On 23.02.2009, at 23:07, Alexandre Bergel wrote:

>> • ( ) New sources file
>
> I do not get this one.

Do we ship Pharo with Squeak39.sources or Pharo1.sources?

>
>
>> • ( ) Prepare second update stream to maintain released version
>
>
> Why would you need a second update stream? PharoInbox2 ?

No. that what happens when you press "update"... 1.0 will get important
bugfixes even while 1.1 is under development. (There are some serious
users involved in Pharo, e.g. companies that plan to use it in  
production,
or university people who want to torture their students with it).

        Marcus


--
Marcus Denker  --  [hidden email]
http://www.marcusdenker.de


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

On 23-Feb-09, at 11:15 PM, Marcus Denker wrote:

>
> On 24.02.2009, at 00:40, David Pennell wrote:
>
>> Milestone 3 includes
>> • closures (may be with the changes of mathieu with a new image
>> format)
>> Didn't we pickup Eliot's recent closure work?
>
> Yes. (so either this is an error or for confusing the enemy ;-)


Ok, well Eliot pushed the closure code out the door, we need to build  
VMs to exploit it.
I've not been able to build the macintosh os-x carbon VM based on it  
yet.
Spent the day trying to integrate Craig's Spoon work with most current  
VMMaker.
Tomorrow (tuesday) I'll see about building a new closure VM.
I note this will be a 4.0.0 VM to note the change from a non-closure  
to closure VM


PS Some bright person might want to code up some RB find templates to  
look for methods
where if you use the closure VM it will possibly  give you different  
behaviour than with the
current VM.

Unless of course everyone feels comfortable in turning block closures  
on, and assuming nothing
will change?

--
=
=
=
========================================================================
John M. McIntosh <[hidden email]>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
=
=
=
========================================================================




_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> PS Some bright person might want to code up some RB find templates to
> look for methods
> where if you use the closure VM it will possibly  give you different
> behaviour than with the
> current VM.

Wouldn't it also require to recompile all methods to get closures?

Have a look at the senders of #fixTemps. I have 37 senders in the
latest Pharo image. These are all places where people had to work
around the shortcomings of the Squeak blocks. With block closures
enabled these blocks should behave the same without fixing their
temps.

For more examples the Seaside code base has a vast collection of
places where it has to work around missing closures. For portability
reasons this is done using #fixCallbackTemps.

> Unless of course everyone feels comfortable in turning block closures
> on, and assuming nothing
> will change?

It could be that some code breaks, because closures behave subtly
different. However if people depend on such code, then it is ambiguous
and buggy in the first place.

I think that closures should be included into mainstream VMs and
images as fast as possible. It is a **major** annoyance that Squeak
has no full block closures even in 2009.

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> You reported a bug half a year ago? Try to recreate it and add a
> comment: This is still a problem
> in #10243 and the way I re-created the problem is this.


How can I close an issue? ( i want to close Issue 472, it has been  
fixed)
I do not see an option for this.

Thanks for reminding us to go over previous issues.

Alexandre

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.






_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

On 24.02.2009, at 11:25, Alexandre Bergel wrote:

>> You reported a bug half a year ago? Try to recreate it and add a
>> comment: This is still a problem
>> in #10243 and the way I re-created the problem is this.
>
>
> How can I close an issue? ( i want to close Issue 472, it has been
> fixed)
> I do not see an option for this.

Maybe one needs some special status to close bugs on the tracker?
No idea...

        Marcus


--
Marcus Denker  --  [hidden email]
http://www.marcusdenker.de


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

On Tue, Feb 24, 2009 at 11:25 AM, Alexandre Bergel <[hidden email]> wrote:
> How can I close an issue? ( i want to close Issue 472, it has been
> fixed)
> I do not see an option for this.

You need to have administrative rights (which you have now). You have
to go to Status field and choose a closed status

--
Damien Cassou
http://damiencassou.seasidehosting.st

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Hi john

what is the work to be done to get alien in pharo?

Stef

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Thanks

Alexandre


On 24 Feb 2009, at 13:33, Damien Cassou wrote:

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.






_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Well the current macintosh VM has the support code in it.
I can't speak for the windows or unix version.

Oomeone *has* to review the alien compiler changes and confirm they  
are ok,
Yesterday I realized there were three class vars missing from  
ParseNode and
1 method from MethodNode.  That I have fixed.

The Pharo team has to decided if they want to make Alien (or some FFI)  
product
part of the base system, versus the current thought of only loading  
FFI if you understand
you need it.

For Sophie loading FFI in to the base app then let us build components  
subclassed by
operating system to provide functionality faster than doing  
primitives, and of course
modifiable by any smalltalker.



On 24-Feb-09, at 5:36 AM, Stéphane Ducasse wrote:

> Hi john
>
> what is the work to be done to get alien in pharo?
>
> Stef

--
=
=
=
========================================================================
John M. McIntosh <[hidden email]>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
=
=
=
========================================================================




_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project