- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Extending SystemBrowser

by StÃ©phane Ducasse

Did you try nautilus? Because it is cool and it will get cooler. It will be the basic default browser and other people will be able to define new tools. Stef > Le 15/03/2012 22:46, StÃ©phane Ducasse a Ã©crit : >> Use Glamour or Spec or OB but not systemBrowser. >> Run away from SystemBrowser >> > > What is the target window for the Pharo Browser? Are there any > aggregating energy to get out a modern incarnation of a system browser > for Pharo. Just wondering. > > Hilaire > > -- > Dr. Geo -- http://www.drgeo.eu > >

March 19, 2012

Re: [Pharo-project] Trying to make KomHttpServer load in 1.4

by StÃ©phane Ducasse

I fixed that too :) On Mar 17, 2012, at 6:00 PM, StÃ©phane Ducasse wrote: > Hi guys > > I saw that TranscriptStream is deprecated in 1.3 and I was looking at the logic of the Logger. > > I do not understand the use of isTranscriptStream especially since it is defined only on Stream ^ false > and the EmergencyEvaluator which is particularly not respecting the stream protocol. > > Any suggestion? > > Stef

March 19, 2012

Re: [Pharo-project] How to load pier in 1.4

by StÃ©phane Ducasse

I fixed KomHttpServer And the ConfigurationOfSeaside30 > Hi > > I'm updating the configuration of citizen to 1.4 and I need to load > Seaside 30 > When I use the MetacelloRepository I get isTranscriptStream question because 1.4 does not have TranscriptStream > > Pier > for Pier I have a problem since it reference to ImageSegments. > > Did any of you produce a correct configuration for Pharo1.4? > > Stef

March 19, 2012

Re: [Pharo-project] Any theme or settings that will speed up a Pharo 1.3 image?

by Eliot Miranda

On Sun, Mar 18, 2012 at 4:57 AM, Stefan Marr <smalltalk(a)stefan-marr.de>wrote: > Hi: > > When trying to debug a Pharo image with a VM that is heavily instrumented > with assertions and runs without any compiler optimizations turned on, it > is crawlingly slow. > (The good old MVC based image is blazingly fast in comparison) > > Are there any tricks to reduce/disable all the possibly fancy things like > transparency, code completion, syntax highlighting easily? > > I already disable the code completion, and syntax highlighting. > I also switched off things like animations, rounded corners, and switched > to the Standard Squeak theme. > > Still, non of these cosmetic changes gave me the noticeable performance > gain I had hoped for. > > Is there anything else I could try to reduce the amount of work the image > is doing? > It blinks the cursor in a text field in the speed I would expect. > But as soon as I start typing, or try to interact with a window, it feels > like I can go for a walk before the image is done. > I noticed some absurd preference checking in standard images a while back, but turning this off made no noticeable different in optimized Cog. Look for uses of Preferences subPixelRenderFonts, e.g. installStrikeFont: foregroundColor:backgroundColor:. There's a non-local return in the default path on preference access. So not having subPixelRenderFonts a defined preference method creates lots on noise when doing VM debugging. > > Thanks > Stefan > > > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: +32 2 629 3525 > > > -- best, Eliot

March 19, 2012

Re: [Pharo-project] Enhancing SmalltalkImage>>recreateSpecialObjectsArray to lower coupling

by Eliot Miranda

Hi Guillermo, On Sun, Mar 18, 2012 at 5:46 PM, Guillermo Polito <guillermopolito(a)gmail.com > wrote: > What about changing #recreateSpecialObjectsArray so having in mind some > classes like Bitmap or Display may not be in the kernel? > This only changes some lines like: > > ... > newArray at: 5 put: (self at: #Bitmap ifAbsent: [ nil ]). > > ... > > newArray at: 13 put: (self at: #Point ifAbsent: [ nil ]). > > ... > > newArray at: 15 put: (self at: #Display ifAbsent: [ nil ]). > > ... > > newArray at: 34 put: (self at: #Point ifPresent: [ :cls | 0@0] > ifAbsent: [ nil ]). > The last one isn't used in Cog (in fact indices 32, 33 & 34 are unused) and probably unused in the Interpreter. David? You may be able to get away with making Bitmap and DIsplay optional. But Point is dug pretty deep into the VM. Point is used for the special selector send bytecodes for #x, #y & #@. For #x & #y there's a check that the class of the receiver is Point, and if so, evaluate in-line. So that is fine; if Point is nil then #x will get sent, rather than evaluated inline. But if the system sends #@ it'll likely crash, trying to create an object whose class is nil. To do what you're proposing properly the VM would need to be modified to be safe. We should perhaps discuss what the right approach is. e.g. if Point is in fact nil then #x #y and #@ would all slow down slightly in normal use checking for the possibility of Point being nil. This isn't an issue in Cog since these messages are compiled to regular sends; but t=in the regular interpreter and the StackInterpreter (used on e.g. Android) it may be. A different approach might be to move these classes to Kernel, or to provide rump classes that raise errors when used, e.g. newArray at: 13 put: (self at: #Point ifAbsent: [ RumpPoint ]). (the rump of something being what's left when you take everything away, rump = behind, bottom etc) > > Does anyone know if this should this break something? > > Guille > -- best, Eliot

March 19, 2012

Re: [Pharo-project] Understanding RunArray>>scanFrom:

by Eliot Miranda

On Mon, Mar 19, 2012 at 12:17 AM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > > On Mar 19, 2012, at 12:27 AM, Guillermo Polito wrote: > > > This method parses a stream from a fileout with styling and generates > the text style specific objects. > > > > Now, > > 1) are we writing that style section in our fileouts? > > No, not anymore. > Are you sure it's not used for class comments? Given pretty-printing there's no need for method text style. But in a class comment (if people knew it was available) it can be quite nice. > > > 2) Is this really necessary in RunArray? It's class comment does not > say anything to me about Text nor TextStyle or stuff: > > > > I would like to clean this up.. the whole machinary for serializing styles > into changesets is very much a big hack. > > but we need to check that we are backward compatible a bit... > > Marcus > > -- > Marcus Denker -- http://marcusdenker.de > > > -- best, Eliot

March 19, 2012

Re: [Pharo-project] [NativeBoost] little improvement

by Igor Stasenko

Actually, my plans were to report the actual position for argument, or even its name. This code: asm jmp: gen failedLabel. <----- change to: gen failWithCode: NBPrimErrBadArgument . will be replaces with something like: gen failWithMessage: self coercionErrorMessage And produced coercionErrorMessage can be quite descriptive, like.. if you having function void foo (int x) and you call it with wrong type (say float) it could say: "Coercion failed: a callout argument #1 should be an Integer" .. or something like that. This will require adding the 'position' ivar to NBExternalType class, so then it can produce such descriptive error messages. Or, well... since we don't know what is the purpose of this.. generator should decide by itself.. So, i would add a new protocol to generator, like: gen failCoercionFor: self ( where self is an instance of NBExternalType) then external type don't needs to know its own position (generator knows it already). -- Best regards, Igor Stasenko.

March 19, 2012

[Pharo-project] Pharo Kernel Reload Tests-Unix - Build # 20 - Still unstable!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

March 19, 2012

Re: [Pharo-project] [NativeBoost] little improvement

by Igor Stasenko

Yes. But there are multiple places like that, because initially i made it working on squeak vm, where primitives has no error codes. now, of course, with Cog, we can report more details , as to what is wrong and where. Javier, i preparing a new config, which will update a debugging support for NB primitives, which will work past 14402 pharo. Because without it, you cannot debug the NB calls. See http://code.google.com/p/pharo/issues/detail?id=5459 for details. On 19 March 2012 16:21, Javier PimÃ¡s <elpochodelagente(a)gmail.com> wrote: > this method doesn't tell why it fails when coercion fails, here is a change > proposed that will save many debugging hours. > > pushAsPointer: gen > "by default, push argument as a bytearray ptr" > "may accept: > - nil > - variable bytes oop > - external address " > | asm proxy notNil done oop Â notExternalAddress | > asm := gen asm. > proxy := gen proxy. > done := asm uniqueLabelName: 'done'. > oop := gen reserveTemp. > "load argument oop" > loader emitLoad: gen to: oop. > "handle nils, if we care" > gen optCoerceNilToNull ifTrue: [ > notNil := asm uniqueLabelName: 'notNil'. > proxy nilObject. > asm cmp: asm EAX with: oop; > jne: notNil; > xor: asm EAX with: asm EAX; > push: asm EAX; > jmp: done; > label: notNil. > ]. > > "handle ExternalAddress, if we care" > gen optAllowExternalAddressPtr ifTrue: [ | oopClass | > oopClass := gen reserveTemp. > notExternalAddress := asm uniqueLabelName: 'notExternalAddress'. > proxy fetchClassOf: oop. > asm mov: asm EAX to: oopClass. > > gen emitFetchClass: NBExternalAddress. > asm cmp: asm EAX with: oopClass. > asm jne: notExternalAddress. > proxy fetchPointer: 0 ofObject: oop. > asm push: asm EAX. > asm jmp: done. > asm label: notExternalAddress. > gen releaseTemps: 1. > ]. > > "the last case is a byte/word array, > simply push a pointer to first indexable field of oop" > > gen optAllowByteArraysPtr ifTrue: [ > proxy isBytesOrWords: oop ifNotJumpTo: gen failedLabel. > proxy firstIndexableField: oop. > asm push: asm EAX. > asm jmp: done. > ]. > asm jmp: gen failedLabel. Â <----- change to:Â gen failWithCode: > NBPrimErrBadArgument . > asm label: done. > > gen releaseTemps: 1. > > > > > -- > Lic. Javier PimÃ¡s > Ciudad de Buenos Aires -- Best regards, Igor Stasenko.

March 19, 2012

Re: [Pharo-project] Morpheas , bringing Morphic to Opengl (3d GUIs)

by Igor Stasenko

great! On 19 March 2012 16:11, Javier PimÃ¡s <elpochodelagente(a)gmail.com> wrote: > I got some time and finished commiting it. > > Steps to load it (I tested with pharo 1.3): > > 1. load NBOpenGL with its configuration. > 2. load NBXLib package from monticello > 3. load NBOpengl-X package from monticello > > Then you can run the example (you'll need tahoma font): > > 4. add the patch I attach. > 5. DoÂ this: > > GLTTRenderingDemo new openInWorld. > > tell if something doesn't work. > > Cheers, > Javier. > > On Tue, Jan 31, 2012 at 12:53 PM, Javier PimÃ¡s <elpochodelagente(a)gmail.com> > wrote: >> >> Hi! IIRC: Two months ago the code was working on windows but needed some >> modifications to create the contexts on the other platforms. Probably Igor >> did that for mac now, and maybe even linux, but I have to test. I remember I >> was working on the NBXLib wrapper so that context creation can be done with >> st code on linux. I will continue with all this this week, I just have to >> download everything and catch up with recent changes and then I'll come >> back. >> >> Cheers, >> Javier. >> >> >> On Tue, Jan 31, 2012 at 10:38 AM, Igor Stasenko <siguctua(a)gmail.com> >> wrote: >>> >>> On 31 January 2012 10:29, dimitris chloupis <thekilon(a)yahoo.co.uk> wrote: >>> > I wanted to ask if NB and COG will support windows as well, I see no >>> > windows >>> > build. >>> there is windows build, just check downloads page of NB project site. >>> >>> > >>> > and here we go with first problem. I am in linux mint 12 32 bit with a >>> > graphic card NVIDIA GEFORCE 6200 . >>> > >>> > I got Cog VM with the Nativeboost plugin + Pharo 1.4 image + >>> > Nativeboost + >>> > NBOpenGL >>> > >>> > This is my workspace >>> > >>> > ---- >>> > Gofer it >>> > Â Â Â Â squeaksource: 'NativeBoost'; >>> > Â Â Â Â package: 'NativeBoost-Installer'; >>> > Â Â Â Â load. >>> > >>> > >>> > NBInstaller install. >>> > >>> > Gofer it >>> > Â Â Â Â squeaksource: 'NBOpenGL'; >>> > Â Â Â Â package: 'ConfigurationOfNBOpenGL'; >>> > Â Â Â Â load. >>> > >>> > ConfigurationOfNBOpenGL project lastVersion load. >>> > >>> > test := (GLTTRenderingDemo new) openInWorld; yourself. >>> > --- >>> > >>> > the problem appears in the last line with an error "No suitable >>> > implementation found for initlising OpenGL context" . Should I assume >>> > it can >>> > find OpenGL libraries or is it a problem with the graphic card drivers. >>> > CC >>> > has been given me problem, but Blender works okish considering it >>> > completely >>> > reliant on OpenGL >>> > >>> >>> Yes, because for linux we don't have an opengl initialization yet. >>> Javier were working on that.. >>> @Javier, what is the status? >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> >> >> >> -- >> Lic. Javier PimÃ¡s >> Ciudad de Buenos Aires > > > > > -- > Lic. Javier PimÃ¡s > Ciudad de Buenos Aires -- Best regards, Igor Stasenko.

March 19, 2012