September 2013 - Pharo-dev - lists.pharo.org

Migration from SqueakSource to SmalltalkHub encounters 403 Forbidden

by Holger Kleinsorgen

Hello, I'm trying to migrate a project from SqueakSource to SmalltalkHub, using the script on the homepage of SqueakSource. However, after successfully pushing a few versions, it encounters an HTTP error: 403 Forbidden. The error can be reproduced, it is always raised when pushing a certain version. Maybe someone has an idea how to get around this issue. Request: a ZnRequest(PUT /mc/hkleinsorgen/InfoVis/main/InfoVis-Examples-hkl.10.mcz) Response: a ZnResponse(403 Forbidden text/plain ) The response also contains an entity: a ZnStringEntity(text/plain receiver of "asTimeStamp" is nil) SqueakSource project: http://www.squeaksource.com/InfoVis SmalltalkHub project: http://www.smalltalkhub.com/#!/~hkleinsorgen/InfoVis I'm using Pharo3.0 (Latest update: #30375). I hope this is the right place to report SmalltalkHub-related issues. -- View this message in context: http://forum.world.st/Migration-from-SqueakSource-to-SmalltalkHub-encounter… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 7, 2013

Re: [Pharo-dev] Should Job use SystemAnnouncer?

by Sean P. DeNigris

Stephan Eggermont wrote > Could we have a separate announcer for this? Are you talking about a class-side announcer or per-job? If the latter, I seem to remember it being important to be able to register for the announcements from an outer scope which may not have access tho the job object. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Should-Job-use-SystemAnnouncer-tp4706044p4707039.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 7, 2013

Re: [Pharo-dev] [smaltalk-gsoc-students] Some news of the UIPainter project

by Erwan Douaille

Hi :) Yes i will. I'm writting a documentation about how to install it, use it, ... add new widgets ... As a part of the GSoC i have to write doc, tests .... I will do some screencasts. A counter is a nice idea. Tonight i will upload a screencast for the counter :) 2013/9/6 Alexandre Bergel <alexandre.bergel(a)me.com> > Hi! > > I've just tried and it seems to work as expected. > Can you please give a short tutorial (could be like 4 pictures) on how to > create a counter: label initialized with 0, +1 and -1 button? > > Cheers, > Alexandre > > > > On Sep 5, 2013, at 3:16 PM, Erwan Douaille <douailleerwan(a)gmail.com> > wrote: > > > Hi, > > > > The GSoC deadlines is 16 september. It means than i have one week to fix > bugs and implements some new features. The best way to find bugs is user > feedbacks. > > > > I will be glad to fix many bugs than you will find. (many bugs found in > 5 minutes with my mentor ...) > > > > Here is instructions to load UIPainter : > > > > Gofer new > > smalltalkhubUser: 'ErwanDouaille' project: 'UIPainter'; > > configurationOf: 'UIPainter'; > > load. > > ConfigurationOfUIPainter load > > > > > > Here is my blog: http://uipainter-gsoc.over-blog.com > > > > Thanks for testing, feedbacks and ideas :) > > > > -- > > Best regards, > > > > Douaille Erwan <douaille.erwan(a)gmail.com> > > > > -- > > You received this message because you are subscribed to the Google > Groups "Smalltalk GSoC students" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to smalltalk-gsoc-students+unsubscribe(a)googlegroups.com. > > For more options, visit https://groups.google.com/groups/opt_out. > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > -- Best regards, Douaille Erwan <douaille.erwan(a)gmail.com>

Sept. 7, 2013

Re: [Pharo-dev] OSProcess for Pharo3.0

by Sean P. DeNigris

Goubier Thierry wrote > Le 06/09/2013 14:13, Marcus Denker a Ã©crit : >> So you want more change in 2.0? You can have that, but you need to >> accept instability. There is no way to have both more changes and more >> stability. > > I'm OK for that. 3.0 is just plainly too unstable, and this is the way > it should be. But 2.0 shouldn't be considered a dead platform ;) I feel the same pain and was motivated enough to create my special interim version mentioned above. And, having previously backported autocompletion (for 1.4 iirc), I can verify that backporting requires significant manpower. I introduced bugs which I then felt compelled to spend many hours fixing (instead of working) because I had broken production software. Given our massive vision, I feel that manpower is better spent moving forward. And I am willing to deal with the pain of feeling one step behind development if it gets us to the system of our dreams. ----- Cheers, Sean -- View this message in context: http://forum.world.st/OSProcess-for-Pharo3-0-tp4706087p4707036.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 7, 2013

Re: [Pharo-dev] [smaltalk-gsoc-students] Some news of the UIPainter project

by Alexandre Bergel

Hi! I've just tried and it seems to work as expected. Can you please give a short tutorial (could be like 4 pictures) on how to create a counter: label initialized with 0, +1 and -1 button? Cheers, Alexandre On Sep 5, 2013, at 3:16 PM, Erwan Douaille <douailleerwan(a)gmail.com> wrote: > Hi, > > The GSoC deadlines is 16 september. It means than i have one week to fix bugs and implements some new features. The best way to find bugs is user feedbacks. > > I will be glad to fix many bugs than you will find. (many bugs found in 5 minutes with my mentor ...) > > Here is instructions to load UIPainter : > > Gofer new > smalltalkhubUser: 'ErwanDouaille' project: 'UIPainter'; > configurationOf: 'UIPainter'; > load. > ConfigurationOfUIPainter load > > > Here is my blog: http://uipainter-gsoc.over-blog.com > > Thanks for testing, feedbacks and ideas :) > > -- > Best regards, > > Douaille Erwan <douaille.erwan(a)gmail.com> > > -- > You received this message because you are subscribed to the Google Groups "Smalltalk GSoC students" group. > To unsubscribe from this group and stop receiving emails from it, send an email to smalltalk-gsoc-students+unsubscribe(a)googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 6, 2013

Re: [Pharo-dev] blog post

by StÃ©phane Ducasse

Thanks for the answers. I'm back in my admin meetings tiring timesâ¦.so my brain works slower than whenI 'm fresh and concentrated. > - Did I get it rid that you want to have a become: that does not require scanning the full memory? > > yes, this is very important for the FFI. I want to be able to pin objects very cheaply, and I think that the way to do that is to a) become: objects in newSpace into pinned objects in oldSpace, and b) have an incremental collector/compactor in oldSpace that doesn't move pinned objects. If objects can be pinned in newSpace I think newSpace will fill up. Soâ¦ I see. And indeed being able to pin an objects will certainly also simplify nativeboost because igor as a "kind of roots" for that reason. > > But with a body as in VW. This is what you mean with the lazyBecome: and the forwarding pointer? > > Here are the relevant paragraphs in SpurMemoryManager's class comment: I love such kind of comments. I always remember good comments and I'm often sad to see how we (pharo) failed to have cool class comments that explain things to the reader. I always loved smalltalk because I could learn. > > - lazy become. The JIT's use of inline cacheing provides a cheap way of avoiding scanning the heap as part of a become (which is the simple approach to implementing become in a system with direct pointers). A becomeForward: on a (set of) non-zero-sized object(s) turns the object into a "corpse" or "forwarding object" whose first (non-header) word/slot is replaced by a pointer to the target of the becomeForward:. The corpse's class index is set to one that identifies corpses (let's say classIndex 1), and, because it is a special, hidden class index, will always fail an inline cache test. The inline cache failure code is then responsible for following the forwarding pointer chain (these are Iliffe vectors :) ) and resolving to the actual target. (In the interpreter there needs to be a similar check when probing the method cache). It has yet to be determined exactly how this is done (e.g. change the receiver register and/or stack contents and retry the send, perhaps scanning the current activation). See below on how we deal with becomes on objects with named inst vars. We insist that objects are at least 16 bytes in size (see 8-byte alignment below) so that there will always be space for a forwarding pointer. Since none of the immediate classes can have non-immediate instances and since we allocate the immediate class indices corresponding to their tag pattern (SmallInteger = 1 & 3, Character = 2, SmallFloat = 5?) we can use all the class indices from 0 to 7 for special uses, 0 = free, and e.g. 1 = isForwarded. > > (and later on) > > As described earlier the basic idea behind lazy become is to use corpses (forwarding objects) that are followed lazily during GC and inline cache miss. However, a lazy scheme cannot be used on objects with named inst vars without adding checking to all inst var accesses, which we judge too expensive. Instead, when becomming objects with named inst vars, we scan all activations in the stack zone, eagerly becomming these references, and we check for corpses when faulting in a context into the stack zone. Essentially, the invariant is that there are no references to corpses from the receiver slots of stack activations. A detail is whether we allow or forbid pinning of closure indirection vectors, or scan the entire stack of each activation. Using a special class index pun for indirection vectors is a cheap way of preventing their becomming/pinning etc. Although "don't do that" (don't attempt to pin/become indirection vectors) is also an acceptable response. I reread it twice but I will have to do it again. Thanks anyway. > > - For Characters since they are immediate (if I got it right) we could use Unicode directly or am'I wrong? > > That's right. This should speed up string access and mean that all characters are unique, so one can use #==. That also sounds exciting :) I have to refresh what I learned and forgot on unicode, encoding and the rest.

Sept. 6, 2013

Re: [Pharo-dev] Grease conflicts #packages with RPackage

by StÃ©phane Ducasse

Hi mariano I have no idea what is a GRPackage. > > packageFromOrganizer: anRPackageOrganizer > "This method returns the package this method belongs to. > It takes into account classes and traits. > If the method is in no package, returns nil by now" > self flag: 'TODO: use anRPackageOrganizer, or better delegate to anRPackageOrganizer'. > ^self origin packages > detect: [ :each | > (each includesSelector: self selector ofClassName: self origin theNonMetaClass originalName) > or: [ each includesSelector: self selector ofMetaclassName: self origin theNonMetaClass originalName]] > ifNone: [ nil ] > > because "each" (which was GRPackage) dnu #includesSelector:ofClassName: > > Problem is that "self origin" answers GRPackage. And GRPackage DOES implement a CLASS side method #packages that answers instances of GRPackage.....not RPackage... > > So...which one do we prefix? GRPackage class #packages to #greasePackages? Yes. > BTW, there are yet more class side implementations of #packages, which are basically subclasses for the HelpSystem (CustomHelp). So we have for example SUnitAPIDocumentation, RegexAPIDocumentation, ProfStefAPIHelp, HelpAPIDocumentation, AnnouncementsAPIDocumentation. Strange. This is probably a method clash. So yes Documentation should probably not redefine packages. > Guess we should update the HelpSystem as well? > > Let me know and I open issues/submit fixes. > > Cheers, > > -- > Mariano > http://marianopeck.wordpress.com

Sept. 6, 2013

Re: [Pharo-dev] VM repository rename

by Camillo Bruni

and talking of the VM repo... I also renamed the HOWTOBUILD to README.md so we have a nice github entry page, and hopefully it will motivate people to maintain it a bit better :P On 2013-09-06, at 16:09, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > yes, in fact I used pharovm because pharo-vm was taken, but I was hoping Camillo does what he actually did :) > > On Sep 6, 2013, at 8:25 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > >> because all other repos have a dash here: https://github.com/pharo-project >> might be the wrong original decision, but at least its consistent, if its >> consistent it can be easily refactored in the future :) >> >> On 2013-09-06, at 15:21, "Esteban A. Maringolo" <emaringolo(a)gmail.com> wrote: >>> Why the dash? >>> Esteban A. Maringolo >>> >>> >>> 2013/9/6 Camillo Bruni <camillobruni(a)gmail.com>: >>>> I renamed the VM repository on github to be more consistent with the other repository names >>>> >>>> OLD: https://github.com/pharo-project/pharovm >>>> NEW: https://github.com/pharo-project/pharo-vm >>>> >>>> Note that github does automatic forwarding, thus old urls will continue to work. >>> >> > >

Sept. 6, 2013

Re: [Pharo-dev] VM repository rename

by Esteban Lorenzano

yes, in fact I used pharovm because pharo-vm was taken, but I was hoping Camillo does what he actually did :) On Sep 6, 2013, at 8:25 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > because all other repos have a dash here: https://github.com/pharo-project > might be the wrong original decision, but at least its consistent, if its > consistent it can be easily refactored in the future :) > > On 2013-09-06, at 15:21, "Esteban A. Maringolo" <emaringolo(a)gmail.com> wrote: >> Why the dash? >> Esteban A. Maringolo >> >> >> 2013/9/6 Camillo Bruni <camillobruni(a)gmail.com>: >>> I renamed the VM repository on github to be more consistent with the other repository names >>> >>> OLD: https://github.com/pharo-project/pharovm >>> NEW: https://github.com/pharo-project/pharo-vm >>> >>> Note that github does automatic forwarding, thus old urls will continue to work. >> >

Sept. 6, 2013

Re: [Pharo-dev] VM repository rename

by Camillo Bruni

because all other repos have a dash here: https://github.com/pharo-project might be the wrong original decision, but at least its consistent, if its consistent it can be easily refactored in the future :) On 2013-09-06, at 15:21, "Esteban A. Maringolo" <emaringolo(a)gmail.com> wrote: > Why the dash? > Esteban A. Maringolo > > > 2013/9/6 Camillo Bruni <camillobruni(a)gmail.com>: >> I renamed the VM repository on github to be more consistent with the other repository names >> >> OLD: https://github.com/pharo-project/pharovm >> NEW: https://github.com/pharo-project/pharo-vm >> >> Note that github does automatic forwarding, thus old urls will continue to work. >

Sept. 6, 2013