October 2014 - Pharo-dev - lists.pharo.org

New Spur trunk image available

by Eliot Miranda

Hi All, finally the Spur Squeak trunk image is updateable. The image in http://www.mirandabanda.org/files/Cog/SpurImages/2014-10-16/ was created today and thanks to Bert Freudenberg's latest Monticello work can be updated independently of the non-Spur trunk. Spur VMs are available in http://www.mirandabanda.org/files/Cog/VM/VM.r3105/ (and later as they appear). Without wanting to appear too overconfident the Spur system looks to be ready for use apart from image segments (which I hope to have working some time next month). I'm really interested in having this stress tested by as many people as possible. Spur really does offer a significant performance and functionality improvement over the current system, but it needs testing to ensure its reliability. Esteban Lorenzano is hard at work on the Pharo bootstrap for Spur so I hope Pharo 4 Spur will be available soon. As far as trunk goes, using Spur alongside non-Spur trunk is going to be difficult to manage for the near future. Right now, Spur modifies the Collections, Compiler, Kernel and System packages, and this is done by auto-editing the non-Spur versions of those packages, something I do periodically as new versions arrive. I also auto-edit trunk configurations (the part of the image update scheme that ensures packages are loaded in the right order when there are dependencies between packages) from non-Spur "update" to Spur "update.spur" forms. This at east means that Spur can keep up with trunk. But it does /not/ provide a way of committing to Collections.spur, Compiler.spur, Kernel.spur or System.spur without getting out of sync with non-Spur trunk. Note that apart from these packages, one /can/ safely commit any other package from a Spur image to trunk. Right now the plan is to release both V3 (the pre-Spur format) and Spur versions of Squeak 4.6 (I hope it'll be called Squeak 5.0). This isn't my preference. I'd like to see just Spur released, once reliability is verified. But I understand the safety and backward-compatibility concerns (Spur won't be able to load V3 image segments, and vice verse). The issue is of course that we have this tricky package situation to manage where, to keep the two systems in sync, modifications to Collections, Compiler, Kernel and System need to be committed from V3 and auto-edited to Spur. I think that's too clumsy to be practicable. Perhaps allowing the two systems to fork and doing a manual merge will be acceptable, but it'll be work to keep them in sync. -- best, Eliot

Oct. 17, 2014

Re: [Pharo-dev] PharoNOS

by phil＠highoctane.be

Le 17 oct. 2014 04:02, "mikefilonov" <mikefilonov(a)gmail.com> a Ã©crit : > > Hi Phil, > > I would really happy to know if this works for you. > > Considering this use case in mind do you have an idea how PharoNOS should > handle the Image? > Should it be embedded in ISO or should it be configured from clean Pharo on > each device? > > For instance, if it is really useful we can have a server which would > re-build the ISO with a requested image. > > What do you think on this? I would have an ssh enabled box and updare things with ansible so that I could update at ton of devices at once. Phil > > > > > -- > View this message in context: http://forum.world.st/PharoNOS-tp4784982p4785039.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Oct. 17, 2014

Re: [Pharo-dev] PharoNOS

by Torsten Bergmann

Hi Mike, > Yes sure I can. So this PharoNOS is basically TinyCore Linux with pure X > server and Pharo running in fullscreen. Yes I already found out. > I have made some auto-installation scripts which configure the disk so no > setup wizard is needed. All space available is mounted under /mnt/universe/ > so you may use that folder to store stuff. Everything else is stored in > memory. Nice side effect of this is an ease of update as you may just > replace the ISO and you'll get the new version of everything (except of the > image of course). Mmmhh ... maybe it should initially boot a downsized "Image selector" image (that allows to download images from CI like Pharo Launcher). Something similar to the usual Linux install wizards to initially setup a machine, configure keyboard layout, clock/timezone, IP/DHCP ... but done in Smalltalk. OSProcess commands could be used underneath to configure the underlying Linux. If this "PharoNOS GraphicalInstall" supports downloading premade image(s) from CI similar to PharoLauncher one could easily configure the machine with for instance with a premade Seaside, Bootstrap, Moose, ... image. This image could also be the fallback to repair, ... > Image is chosen on start by reading the "/mnt/universe/image" file. You may > upload other image and change this file so after reboot it will start with a > new one. This info should be included in the docu in the pillarhub article (if not already) > Jan Tomsa has pointed out that the disk setup is quite dangerous > (https://twitter.com/DetektivTomy/status/522860736155238401) I plan to > update it later today with more safe solution which will not erase all the > data. Nice > Also I think Pharo should be run under root user so you can bind > to any port. Yes, I have the following quick setup scenario in mind: downlod the ISO, start a virtual computer with it (in virtualization software or on a cloud server). Use the Pharo based setup wizard (see above) to setup keyboard layout, give a fixed IP, adjust the clock, ... and download a premade Seaside (or other webframework image) from CI. Now run on port 80, configure another port and give a name to the machine in the network. This way one could easily setup virtualized network machines to provide network delivered applications. > I can also put more 3d-party libs like sqlite3, so we can have some > interesting apps for the terminals run on embedded Pharo :) However I need > some feedback on what is needed. sQLite3 would be cool, also unqlite. Both are small shared libs and embeddable. This way one could load the Native Boost bindings for either SQLite3 or PUnqlite and use an embedded RDBMS or a NoSQL Database and also load/use Glorp/Voyage or other to access it. > So that is it, all comments are welcome. A specific small image demonstrating Pharo 3 or 4 lively in the web browser also comes up as an idea. Emulating and bootstrapping an x86 machine on top of JavaScript is possible these days. Look at http://copy.sh/v86/ to bootstrap a linux in your browser. I tried to run the ISO with it, but it hangs. I guess it is due to query for network (which is not available in browser). Maybe a special non-network image could be built. This way we could include a premade machine in the Pharo Project webpage so people can directly bootstrap and play with Pharo. Similar to SqueakJS (http://bertfreudenberg.github.io/SqueakJS/) but without having to port the Pharo VM to JS. >I'll take a look at AioPlugin issue. How I can test if it is loaded well? I loaded OSProcess from the config browser and used (PipeableOSProcess command: 'pwd') output. While doing this the system lamented about the missing AioPlugin. Bye T.

Oct. 17, 2014

Re: [Pharo-dev] Rectangle differences between Pharo 3 & 4

by stepharo

On 17/10/14 03:55, Ben Coman wrote: > > I notice a difference between Pharo 3 & 4... > > Rectangle left: 4 right: 3 top: 2 bottom: 1. > Build 30856 --> (4@2) corner: (3@1) > Build 40309 --> (3@1) corner: (4@2) > > Rectangle origin: (4@1) corner: (3@2) > Build 30856 --> (4@1) corner: (3@2) > Build 40309 --> (3@1) corner: (4@2) > > I remember some report of Stef and Igor fixing some Rectangle stuff, > but I wasn't paying attention in detail. Is this related? What is the > intent? The intent is that a rectangle is not a pair of point (especially for damage rectangle). Now a rectangle cannot have negative extent > > I noticed this reviewing the some tests added by mschepens > https://pharo.fogbugz.com/default.asp?14221 > > It seems now there is an assumption that rectangles always go from > top-left to bottom-right. I wonder what would be the effect (in a > hypothetical application) if I am dragging a rectangular "rubber band" > (as is commonly done for selection in graphics programs) and I move the > secondary/corner point of a rectangle up and left of the first/origin > point? > > Would it be correct to say that Points and Rectangles are immutable, and > so maybe its not a problem, such that a "rubber band" selection would be > creating new rectangles each mouse move? I do not know but why not. And you can use "point:point:" to create a rectangle you are not forced to use corner: > > btw, Rectangle left: 1 right: 2 top: 3 bottom: 4. > Build 30856 --> (1@3) corner: (2@4) > Build 40309 --> (1@3) corner: (2@4) > > cheers -ben > > >

Oct. 17, 2014

Re: [Pharo-dev] Playground and its current usability in Pharo4.0 Latest update: #40307

by Tudor Girba

Hi, On Thu, Oct 16, 2014 at 10:58 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > Tudor wrote: > >Indeed. This was a discussion I wanted to spawn as well. I would prefer > to change the name from Workspace to Playground in the World Menu. The > reason is >that the Playground is such a distinct departure from the > Workspace that it deserves a different name. > > I do not think it is a departure from the Workspace concept. > > Therefore I would keep "Workspace" for the menu item name and the window > name. It would be enough if the initial > tab is called "Playground" because one can play in the code pane (or do > serious stuff). > I disagree. Workspace has a very specific meaning in the way it is being used, and this is now obsolete. > This way we would keep up with a known concept (also from other IDE's) You mean like the Playground in Swift (btw, we named it playground before Swift appeared)? :) The philosophy of the name is to support the idea that in Pharo we play with objects, and play with do in a Playground. But, we can still find another name if wanted, just not workspace. For example, it can be something about starting, or entering a space. I would also prefer having something that ends with an "er" or "or" like the Inspector or Debugger. it meets what people would expect and > no books would have to be rewritten ;) > I disagree again. Books will actually have to rewritten :) BTW: Squeak had a goodie with something similar back in the days (cant > remember the name). It was neat as one > could assemble different objects and different object representations > in one navigateable window. That is great to hear. Was it the work of Marcel Taeumel on Vivide ( http://www.taeumel.eu) or something else? Only, the Playground is not just windows stacked to one another, it's a whole session that can be reasoned about. >>I would suggest to use the well known order "Cut","Copy","Paste". > >Thanks for noticing. This will be fixed. > > Thanks! > > >Indeed, we had a debate about the name. I proposed the solution 3b you > mention, but it was decided > >that it would be too confusing to change the Cmd+i action at this time, > and we chose "Go" to be > >the name of the action that is mapped on Cmd+g. > > Here we agree - I would have choosen 3b as well. Decided by whom? Did I > miss the discussion in the > list or was it offlist? > You missed the discussion. It was on this list, but we can start it again. Could you open another thread? >>...icons... > >This is a known issue and we will look at it soon. > > Sounds good. > > >At the moment, GT is an external project and the contributions should > happen directly in its repository. > > Then please add me to the repo. Still the process is unclear - will I > still provide a slice with > issue number or will I change the config. > At the moment, we are taking an optimistic approach to committing, so you can commit directly in the GT repository. You can also commit either in your own repository and send us a ping. Because of the optimistic approach, it is better to have a discussion beforehand, either through an issue or via the mailing list. When we are all happy (it can be that a change is reverted), we create a new stable version that afterwards has to be integrated into Pharo. I believe that after a while, we should eliminate the last step and have Pharo integrate the latest stable, but we need a transition period. It is not very lucky that this process was started (without > discussion/announcement/description first > and only for specific packages). > Again, you missed this discussion. Btw, this is how Zinc was handled since quite a long time, and we want to move Pharo to be handled via configurations in separate repositories from now on. This is a way to scale the effort by not making the central team responsible for everything. Cheers, Doru > Thx > T. > > -- www.tudorgirba.com "Every thing has its own flow"

Oct. 17, 2014

Re: [Pharo-dev] PharoNOS

by mikefilonov

Wow, this is an interesting stuff. Is this a kind of desktop manager written on Pharo? From what I can see on video it support calling external processes like open-office. Does it work on Pharo 3.0 ? -- View this message in context: http://forum.world.st/PharoNOS-tp4784982p4785054.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Oct. 17, 2014

Re: [Pharo-dev] PharoNOS

by S Krish

Guess this was couple of years back.. TCL + Pharo on a Virtual Box: My play with it then.. https://plus.google.com/photos/101656219013170129431/albums/571774973947681… On Fri, Oct 17, 2014 at 9:52 AM, S Krish <krishnamachari.sudhakar(a)gmail.com> wrote: > > Lovely... TCL + Pharo .. ! > > > > > > On Fri, Oct 17, 2014 at 7:17 AM, mikefilonov <mikefilonov(a)gmail.com> > wrote: > >> Hi Torsten, >> >> Yes sure I can. So this PharoNOS is basically TinyCore Linux with pure X >> server and Pharo running in fullscreen. >> >> I have made some auto-installation scripts which configure the disk so no >> setup wizard is needed. All space available is mounted under >> /mnt/universe/ >> so you may use that folder to store stuff. Everything else is stored in >> memory. Nice side effect of this is an ease of update as you may just >> replace the ISO and you'll get the new version of everything (except of >> the >> image of course). >> >> Image is chosen on start by reading the "/mnt/universe/image" file. You >> may >> upload other image and change this file so after reboot it will start >> with a >> new one. No safeguards here though - if it breaks there is no cure for it >> yet :( I'm thinking over on how to implement some recovery on "Image not >> available or broken". Hm, just now get the idea to run Image chooser if >> default image failed. Is it available on linux? >> >> Jan Tomsa has pointed out that the disk setup is quite dangerous >> (https://twitter.com/DetektivTomy/status/522860736155238401) I plan to >> update it later today with more safe solution which will not erase all the >> data. The idea is to format the disk without a partition table or to work >> from RAM. Also I think Pharo should be run under root user so you can bind >> to any port. >> >> I can also put more 3d-party libs like sqlite3, so we can have some >> interesting apps for the terminals run on embedded Pharo :) However I need >> some feedback on what is needed. >> >> So that is it, all comments are welcome. >> >> >> >> >> >> >> -- >> View this message in context: >> http://forum.world.st/PharoNOS-tp4784982p4785034.html >> Sent from the Pharo Smalltalk Developers mailing list archive at >> Nabble.com. >> >> >

Oct. 17, 2014

Re: [Pharo-dev] PharoNOS

by S Krish

Lovely... TCL + Pharo .. ! On Fri, Oct 17, 2014 at 7:17 AM, mikefilonov <mikefilonov(a)gmail.com> wrote: > Hi Torsten, > > Yes sure I can. So this PharoNOS is basically TinyCore Linux with pure X > server and Pharo running in fullscreen. > > I have made some auto-installation scripts which configure the disk so no > setup wizard is needed. All space available is mounted under /mnt/universe/ > so you may use that folder to store stuff. Everything else is stored in > memory. Nice side effect of this is an ease of update as you may just > replace the ISO and you'll get the new version of everything (except of the > image of course). > > Image is chosen on start by reading the "/mnt/universe/image" file. You may > upload other image and change this file so after reboot it will start with > a > new one. No safeguards here though - if it breaks there is no cure for it > yet :( I'm thinking over on how to implement some recovery on "Image not > available or broken". Hm, just now get the idea to run Image chooser if > default image failed. Is it available on linux? > > Jan Tomsa has pointed out that the disk setup is quite dangerous > (https://twitter.com/DetektivTomy/status/522860736155238401) I plan to > update it later today with more safe solution which will not erase all the > data. The idea is to format the disk without a partition table or to work > from RAM. Also I think Pharo should be run under root user so you can bind > to any port. > > I can also put more 3d-party libs like sqlite3, so we can have some > interesting apps for the terminals run on embedded Pharo :) However I need > some feedback on what is needed. > > So that is it, all comments are welcome. > > > > > > > -- > View this message in context: > http://forum.world.st/PharoNOS-tp4784982p4785034.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

Oct. 17, 2014

Re: [Pharo-dev] PharoNOS

by David T. Lewis

On Thu, Oct 16, 2014 at 06:52:48PM -0700, mikefilonov wrote: > I'll take a look at AioPlugin issue. How I can test if it is loaded well? With OSProcess installed, evaluate "AioEventHandler aioPluginPresent" Dave

Oct. 17, 2014

Re: [Pharo-dev] PharoNOS

by mikefilonov

Hi Phil, I would really happy to know if this works for you. Considering this use case in mind do you have an idea how PharoNOS should handle the Image? Should it be embedded in ISO or should it be configured from clean Pharo on each device? For instance, if it is really useful we can have a server which would re-build the ISO with a requested image. What do you think on this? -- View this message in context: http://forum.world.st/PharoNOS-tp4784982p4785039.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Oct. 17, 2014