Hi reinout
> Please bear in mind that I'm a newbie to Squeak, so some of these
> questions may be rather naive.
We welcome newbie like you :)
> One of my motivations is to evaluate the future viability of Pharo as
> a vehicle for commercial applications and whether it warrants to lobby
> for resources being allocated to its development.
>
> So here goes:
>
> The wiki mentions 'kernel' and 'MiniImage' as not being in scope of
> Pharo.
> What does that entail, does this mean that discussions about allowing
> nil in Sets are out of scope?
ok this is old.
this was by reference to the effort of pavel to create a minimal kernel.
We did not want to stress that the only effort of pharo was to have a
small kernel.
Our effort is to have a modular, clean, tested smalltalk (which will
probably have a small kernel).
> What is the status of the dev-image? As delivered the tools are broken
> (because context menus on the source pane raise an UHE that is induced
> by OB-Enhancements, issue 904), is it actively used by the main
> committers or is the core image the place to be?
The dev image is alpha like pharo.
Some of the OB code changes under the feet of david. He promised us to
fix that.
> Even more confusingly the above issue has been marked as fixed this
> night but if I do a World->System->Software Update the bug persists in
> my image.
the update is only working for the core because OB is not part of
pharo but an add-on.
And the add-on are not managed by the pharo stream of changes but by
an update of
the projects in the pharo Universe (yes this is complex but we do not
want that people can
say that we are hijacking squeak tools).
> When I looked into fixing it myself I got confused (because I looked
> at InstallScript.st), it seems the code comes from various
> repositories -- not a single Pharo respository/branch. Are these
> various repositories Pharo-specific and maintained over Pharo-Inbox or
> do I need to submit fixes to different places?
ok
for pharo code
we have
Pharo (our components)
PharoInbox (for people to post)
PharoTaskForces (for effort related to pharo but not ready yet)
PharoTreatedInbox (once we clean the inbox we do not delete but move
to an archive).
> I guess as a Squeak newbie I need a high-level overview on the wiki on
> how code and fixes flow within Pharo, towards Squeak and towards the
> various tool maintainers (and back to Pharo of course, the upstream/
> downstream story). What is the story when such tools and Pharo become
> incompatible and need to fork (or are they already forked)?
Ok here it is:
- when a fix for pharo arrives via the inbox
- we treat it
-> reject with reason
-> integrate it in the pharo core stream
- when a fix arrives for a tool we cannot do too much
besides asking that the maintainer push it into his code
-> this implies that some tools may fork.
> Is there a vision on long-term support?
You mean are they pharoers that you can pay to maintain and provide
support?
Yes I imagine that you can pay john mcintosh, mike rueger and some
others to
offer support.
> Pharo wants to be agile and be free to change at will (IMO a good
> decision) but if it is to be viable at my job there need to be
> versions that receive long-term support (the 'professional' aspect of
> Pharo).
Yes
Normally with Squeak, severe bugs and selected one where retrofitted
in old versions. This way seaside 3.8 users got important fixes when
we did 3.9.
> At least bug fixes (and hopefully speed enhancements) need to be
> ported back to an 'LTS' release for quite a while (I'm thinking three
> to four years here) and on a consistent/reliable basis if Pharo is to
> be viable for the kind of projects I work on.
Since all the code is and will be available either people will have to
do it
or they should pay for it. We will be able to do the critical ones only.
> Porting our projects (and project specific tool enhancements)
> forwards turns out to be very
> expensive (even in a 'conservative' environment like VisualWorks) so a
> mechanism needs to be in place to avoid needing too many porting
> moments over the lifetime of our projects (think 10+ years).
> The process of updating the dev image is excruciatingly slow, is this
> normal?
Yes the complete code of the package is sent, parsed, compared.....
We do not have bytecode and the packageInfo used by Monticello is
really slow since it simulates packages by scanning the complete
systemOrganisation
all the time. I started to write a real package class with pointers to
replace that.
But I do that on my spare time.
> The process seems to be CPU bound and takes ages for what I consider a
> small amount of changes - in its current state it would be unusable
> for the process we use at work, it will need to be brought back to
> well under a minute as opposed to the twenty (or so) minutes it took
> me yesterday. What is the background and vision for the future on
> this issue?
The vision is bytecode loader + real package + probably using
monticello 2
when it will be ready.
> Let me finish with a quick and easy newbie question:
> where do I find the profiler tools for Pharo?
I like this question. We need more of profiler and fixes.
MessageTally
SpaceTally
bench
millisecondsToRun:
Reinout. We know that the road will be long and we do not have engineers
but we will do it small steps at a time and see if we succeed.
stef
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
