- Pharo-dev - lists.pharo.org

Downloading the latest 40 Image -> Error

by HernÃ¡n Morales Durand

FYI $ wget -O- get.pharo.org/40+vm | bash --2015-04-04 18:41:59-- http://get.pharo.org/40+vm Resolving get.pharo.org... 128.93.162.72 Connecting to get.pharo.org|128.93.162.72|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 2885 (2.8K) [text/html] Saving to: `STDOUT' 100%[======================================>] 2,885 --.-K/s in 0.001s 2015-04-04 18:42:00 (2.54 MB/s) - written to stdout [2885/2885] Downloading the latest 40 Image: http://files.pharo.org/image/40/latest.zip [image.MJSoCf/image.zip] End-of-central-directory signature not found. Either this file is not a zipfile, or it constitutes one disk of a multi-part archive. In the latter case the central directory and zipfile comment will be found on the last disk(s) of this archive. unzip: cannot find zipfile directory in one of image.MJSoCf/image.zip or image.MJSoCf/image.zip.zip, and cannot find image.MJSoCf/image.zip.ZIP, period.

April 4, 2015

Re: [Pharo-dev] UpdatedPharoByExample for 3.0, 4.0, 5.0

by Dmitri Zagidulin

I agree 100% that we should keep separate book versions for the corresponding Pharo versions. Specifically: - Use the 'master' branch for the current stable version (4.0). Basically, the way things are right now. This at least won't break existing CI jobs (tests and PDF generation). - Have a 3.0 and a 5.0 branch (or maybe just 5.0, going forward, if there's not enough demand or reason to do 3.0). - When time comes for 5.0 release, the 5 branch gets moved to master, and the previous master gets moved to a 4.0 branch. And so on. (Btw, I don't think it would make sense for us to use tags like 'Pharo-4-final', since the whole point about having a book under source control like that is that it's continuously improving. It makes sense to freeze software with tags (well, sort of, except you still end up making bugfix releases), but less so for books.) I think the time / energy investment problem that stepharo was mentioning has to do with: 1) setting up the Jenkins and Travis CI jobs for the various branches. Annoying, but at least it's just an initial effort (plus subsequent bursts of effort for each Pharo version branch). 2) porting new content (or even revisions) to multiple versions. So, if a new chapter is added to the 5.0 branch in the future, is it then a requirement to also back-port it to 4.0 (and 3.0, if we have it)? (And to do the resulting small tweaks to make sure the code still works for that version, change the screenshots and so on)? This is where most of the effort comes in, as I see it. The solution is probably in relaxed expectations. We could have an implicit (or even explicitly stated in the readme) policy that new revisions will only propagate from the current version upwards (but not backwards). Or, even simpler, just leave it up to individual contributors' motivations -- meaning, new revision comes in, we open up tickets to back-port it to previous versions, and if somebody cares enough to do it, it'll get ported. On Sat, Apr 4, 2015 at 10:19 AM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > stepharo wrote > > there is a huge time / energy investment problems. > > I don't see it. The simplest thing (which is 0 extra work AFAICT) would be > to tag the last version before we start updating for 5.0 as something like > 'Pharo-4-final'. Almost as easy would be to have a branch per version, so > e.g. typos could be merged back if someone was interested. But maybe I'm > missing something - where specifically do you see the time & energy > investment? Because I think we could've set it up in less time than it took > me to write this reply! > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/UpdatedPharoByExample-for-3-0-4-0-5-0-tp4817514p48175… > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

April 4, 2015

Re: [Pharo-dev] VM and .sources in separate dirs question

by Dmitri Zagidulin

Ok, that's awesome. Thank you for explaining! On Sat, Apr 4, 2015 at 8:50 AM, Max Leske <maxleske(a)gmail.com> wrote: > > On 03 Apr 2015, at 19:02, Dmitri Zagidulin <dmitri(a)zagidulin.net> wrote: > > Do you happen to know how it does it? (I wouldn't know where to look, in > the source code). Does it still work if you move the sources to another > directory, from your current one? Does Pharo do a whole-disk search every > time? (Or just when it doesn't find them?) > > On Fri, Apr 3, 2015 at 12:00 PM, Max Leske <maxleske(a)gmail.com> wrote: > >> >> On 03 Apr 2015, at 17:55, Dmitri Zagidulin <dmitri(a)zagidulin.net> wrote: >> >> On Fri, Apr 3, 2015 at 11:49 AM, Max Leske <maxleske(a)gmail.com> wrote: >>> >>> > that you can keep the VM and .sources in different directories? How do >>> you tell the VM where to locate the sources? >>> >>> You donât. Itâs detected automagically! >>> >> >> Wait, how does it know which .sources file to pick? :) What if there are >> .sources from multiple versions of Pharo, etc, lying around on the hard >> drive? >> >> > No, Pharo wonât search your disk, that would take way too long. Basically, > the image tries to find the sources in two places: > 1. the image directory > 2. the vm directory > > In reality Pharo tries to do a bit more. The places Pharo looks in are > listed in OSPlatform>>potentialLocationsOfSourcesFile (and subclasses). > > See also PharoFilesOpener>>openSources. > > Note that the Pharo implementation has probably diverged a bit from the > one that Squeak uses / used to use. > > Cheers, > Max > > >> >> The image decides which sources file it needs. I have all of mine in a >> single directory with all the different VMs. Works like a charm. >> > > >

April 4, 2015

Re: [Pharo-dev] UpdatedPharoByExample for 3.0, 4.0, 5.0

by Sean P. DeNigris

stepharo wrote > there is a huge time / energy investment problems. I don't see it. The simplest thing (which is 0 extra work AFAICT) would be to tag the last version before we start updating for 5.0 as something like 'Pharo-4-final'. Almost as easy would be to have a branch per version, so e.g. typos could be merged back if someone was interested. But maybe I'm missing something - where specifically do you see the time & energy investment? Because I think we could've set it up in less time than it took me to write this reply! ----- Cheers, Sean -- View this message in context: http://forum.world.st/UpdatedPharoByExample-for-3-0-4-0-5-0-tp4817514p48175… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

April 4, 2015

Re: [Pharo-dev] Brand new modern Spotter design!

by stepharo

doru it would be fun to have an even redder GTSpotter and some colored windows In a dark background it can be really "efficient" :) Stef Le 3/4/15 18:27, Tudor Girba a Ã©crit : > I wonder :) > > Doru > > On Fri, Apr 3, 2015 at 3:14 PM, Sven Van Caekenberghe <sven(a)stfx.eu > <mailto:sven@stfx.eu>> wrote: > > Maybe the color is an April 1st joke ? > > > On 03 Apr 2015, at 10:30, Tudor Girba <tudor(a)tudorgirba.com > <mailto:tudor@tudorgirba.com>> wrote: > > > > Universal :)))) > > > > Doru > > > > On Fri, Apr 3, 2015 at 9:47 AM, Stephan Eggermont > <stephan(a)stack.nl <mailto:stephan@stack.nl>> wrote: > > On 01/04/15 11:53, Tudor Girba wrote: > > Nah, you have to experience it first hand yourself. It's too cool to > > experience it via a dead picture. > > > > On wednesday we used it in the devnology workshop. > > It just works, no participants had any remarks :) > > > > Stephan > > > > > > > > > > > > > > -- > > www.tudorgirba.com <http://www.tudorgirba.com> > > > > "Every thing has its own flow" > > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > > "Every thing has its own flow"

April 4, 2015

Re: [Pharo-dev] UpdatedPharoByExample for 3.0, 4.0, 5.0

by stepharo

there is no technical problem. there is a huge time / energy investment problems. We will reintroduce in pillar the possibility to run tests. and we will add support (should check what stephan did to get automatic scrneeshots). Stef Le 4/4/15 15:04, Sean P. DeNigris a Ã©crit : > Would it make sense to freeze the documentation for each image version? Maybe > a branch per image? This way, people who choose/need to work with previous > image versions have an accurate reference. From my limited Git experience it > shouldn't be much extra work. > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/UpdatedPharoByExample-for-3-0-4-0-5-0-tp4817514.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > >

April 4, 2015

Re: [Pharo-dev] UpdatedPharoByExample for 3.0, 4.0, 5.0

by kilon alios

I agree it makes sense, we can use git tags , or branches. Having separate docs for every version is how it works for all other languages I have used. Its zero extra work. I dont know about the generation of pdfs though, I am not familair with CI / Jenkins and how easy it is to assign specific builds to git tags / branches. On Sat, Apr 4, 2015 at 4:04 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Would it make sense to freeze the documentation for each image version? > Maybe > a branch per image? This way, people who choose/need to work with previous > image versions have an accurate reference. From my limited Git experience > it > shouldn't be much extra work. > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/UpdatedPharoByExample-for-3-0-4-0-5-0-tp4817514.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

April 4, 2015

UpdatedPharoByExample for 3.0, 4.0, 5.0

by Sean P. DeNigris

Would it make sense to freeze the documentation for each image version? Maybe a branch per image? This way, people who choose/need to work with previous image versions have an accurate reference. From my limited Git experience it shouldn't be much extra work. ----- Cheers, Sean -- View this message in context: http://forum.world.st/UpdatedPharoByExample-for-3-0-4-0-5-0-tp4817514.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

April 4, 2015

Re: [Pharo-dev] Binding semantics of SystemDictionary

by Max Leske

> On 31 Mar 2015, at 23:12, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > Thanks Nicolas. I was hoping to see a bit more activity on this thread so I didnât reply immediately. > not only the globals but the methods in MethodDictionary too :) Ok, that might even be worse. AFAIK MethodDictionary is treated as a special class by the VM. So storing other objects in there may be a real problem, not just a philosphical one. CCâing vm-dev on this. > It might be a feature, it's just that it's unused because of limited IDE and compiler. If you look far enough, almost anything can be considered a featureâ¦ :) > > 2015-03-31 20:49 GMT+02:00 Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>>: > Hi > > Tommaso and I, while hacking on Fuel, today discovered that globals in Pharo can have very weird bindings (I guess some of you already know that). For example: > > class := Class new > setName: 4; > yourself. > Smalltalk > at: class name > put: class. > > So we now have a class with name 4 (which is a SmallInteger): > > self assert: (Smalltalk at: 4) == class. > > > There are basically two different issues: > 1. SystemDictionary will store any kind of association, not only symbols / strings > 2. SystemDictionary is an IdentityDictionary and as such two equivalent but not identical keys will not resolve to the same object: > > class := Class new > setName: (String streamContents: [ :s | s nextPutAll: 'someName']); > yourself. > Smalltalk > at: class name > put: class. > > Smalltalk > at: (String streamContents: [ :s | s nextPutAll: 'someNameâ]) > ifAbsent: [ false ]. âââ> falseâ > > > In Fuel we simply assume that any key to a global is either a ByteString or ByteSymbol. If thatâs not the case bad things happen. > It would help us a lot if we could clear up the semantics of bindings in SystemDictionary: > 1. Are bindings with keys that are not ByteString or ByteSymbol valid? > 2. Should we keep allowing ByteString as keys to globals (ByteSymbol guarantees identity)? > 3. If we allow ByteString, do we also allow WideString? > 4. Would âtype checksâ on SystemDictionary incur a big performance penalty? > > > Any suggestions are welcome. > > Cheers, > Max >

April 4, 2015

Re: [Pharo-dev] Binding semantics of SystemDictionary

by Max Leske

Bumpâ¦ I really think this is something we should talk aboutâ¦ Otherwise Iâll open an issue on phogbugz. > On 01 Apr 2015, at 22:58, stepharo <stepharo(a)free.fr> wrote: > > Please do not use Smalltalk at: > We will ban it for real! Good to know. I wasnât aware of that. > > Stef > > Le 31/3/15 20:49, Max Leske a Ã©crit : >> Hi >> >> Tommaso and I, while hacking on Fuel, today discovered that globals in Pharo can have very weird bindings (I guess some of you already know that). For example: >> >> class := Class new >> setName: 4; >> yourself. >> Smalltalk >> at: class name >> put: class. >> >> So we now have a class with name 4 (which is a SmallInteger): >> >> self assert: (Smalltalk at: 4) == class. >> >> >> There are basically two different issues: >> 1. SystemDictionary will store any kind of association, not only symbols / strings > > arghhhh Exactly the sound I made when we discovered that :) > >> 2. SystemDictionary is an IdentityDictionary and as such two equivalent but not identical keys will not resolve to the same object: >> >> class := Class new >> setName: (String streamContents: [ :s | s nextPutAll: 'someName']); >> yourself. >> Smalltalk >> at: class name >> put: class. >> >> Smalltalk >> at: (String streamContents: [ :s | s nextPutAll: 'someNameâ]) >> ifAbsent: [ false ]. âââ> falseâ >> >> >> In Fuel we simply assume that any key to a global is either a ByteString or ByteSymbol. If thatâs not the case bad things happen. >> It would help us a lot if we could clear up the semantics of bindings in SystemDictionary: >> 1. Are bindings with keys that are not ByteString or ByteSymbol valid? >> 2. Should we keep allowing ByteString as keys to globals (ByteSymbol guarantees identity)? >> 3. If we allow ByteString, do we also allow WideString? >> 4. Would âtype checksâ on SystemDictionary incur a big performance penalty? >> >> >> Any suggestions are welcome. >> >> Cheers, >> Max >> > >

April 4, 2015