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