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

Relation between Garage PG and PGv2

by Esteban A. Maringolo

Hi all, and Guille Polito in particular, I'm loading the Garage classes into Pharo 4, and I see the Garage-Postgres package "duplicates" the classes of the PostgresV2 package, but instead of using the PG prefix, it uses the GA prefix. This is in particular with the case of Garage-Postgres-Protocol package. Why is it so? Because even GAConnection>>#buildDefaultConnectionArgs (which is a replica of PGConnection) references PGConnectionArgs instead of GAConnectionArgs, which is the replica of the first. QUESTION: Isn't Garage a "common API" for the *existing* drivers? (like a common wrapper), and if so it delegates the protocol handling to the real driver? In the PostgresV2 package in this case, to PG prefixed classes. Regards! Esteban A. Maringolo

Oct. 12, 2015

Re: [Pharo-dev] Another pass on catalog web-site (Styling)

by Ben Coman

looks cool. thanks Esteban. cheers -ben On Mon, Oct 12, 2015 at 6:25 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi, > > I made another pass on catalog web-site. This time I just enhanced a bit the stylingâ¦ still a lot to do but is looking better and better: http://catalog.pharo.org (you might need a force refresh) > > But in fact, this announce is just an excuse to remember you to enhance your configurations with catalog information as described here: http://catalog.pharo.org/catalog/note-for-developers > Also, if your configuration is proved to work on Pharo 3, 4 or 5, please copy your configuration into that repository, to avoid it to appear under âUnstableâ tag. > > The Catalog is just as good as the information it provides: there is A LOT of very good packages no one will ever notice (like Aconcagua, for example), that does not provide *any* information and therefore they will never be used :( > > PLEASE PLEASE PLEASE UPDATE YOUR CONFIGURATIONS! > > cheers, > Esteban

Oct. 12, 2015

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50382 Home: https://github.com/pharo-project/pharo-core

Oct. 12, 2015

[pharo-project/pharo-core] 9ef1c3: 50382

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 9ef1c30b540a7418d150dede106373b6f4ef3111 https://github.com/pharo-project/pharo-core/commit/9ef1c30b540a7418d150dede… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-10-12 (Mon, 12 Oct 2015) Changed paths: M ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/symbolic versions/stable_.st A ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version20_.st A Deprecated50.package/MultistateLabelMorph.class/README.md A Deprecated50.package/MultistateLabelMorph.class/definition.st A Deprecated50.package/MultistateLabelMorph.class/instance/accessing/colorMap.st A Deprecated50.package/MultistateLabelMorph.class/instance/accessing/colorMap_.st A Deprecated50.package/MultistateLabelMorph.class/instance/as yet unclassified/defaultColorMap.st A Deprecated50.package/MultistateLabelMorph.class/instance/as yet unclassified/disabledColor.st A Deprecated50.package/MultistateLabelMorph.class/instance/as yet unclassified/disabledColor_.st A Deprecated50.package/MultistateLabelMorph.class/instance/as yet unclassified/drawOn_.st A Deprecated50.package/MultistateLabelMorph.class/instance/as yet unclassified/initWithContents_font_emphasis_.st A Deprecated50.package/MultistateLabelMorph.class/instance/as yet unclassified/interactionState_.st A Deprecated50.package/MultistateLabelMorph.class/instance/as yet unclassified/mouseOverColor_.st A Deprecated50.package/MultistateLabelMorph.class/instance/as yet unclassified/normalColor_.st A Deprecated50.package/MultistateLabelMorph.class/instance/as yet unclassified/pressedColor_.st A Deprecated50.package/MultistateLabelMorph.class/instance/as yet unclassified/selectedColor_.st A Deprecated50.package/MultistateLabelMorph.class/instance/as yet unclassified/selectedDisabledColor_.st A Deprecated50.package/MultistateLabelMorph.class/instance/as yet unclassified/selectedMouseOverColor_.st A Deprecated50.package/MultistateLabelMorph.class/instance/as yet unclassified/selectedPressedColor_.st A Deprecated50.package/MultistateLabelMorph.class/instance/initialization/initialize.st M Komitter.package/Komitter.class/instance/announcement/mcPackageModified_.st R Morphic-Widgets-Basic.package/MultistateLabelMorph.class/README.md R Morphic-Widgets-Basic.package/MultistateLabelMorph.class/definition.st R Morphic-Widgets-Basic.package/MultistateLabelMorph.class/instance/accessing/colorMap.st R Morphic-Widgets-Basic.package/MultistateLabelMorph.class/instance/accessing/colorMap_.st R Morphic-Widgets-Basic.package/MultistateLabelMorph.class/instance/as yet unclassified/defaultColorMap.st R Morphic-Widgets-Basic.package/MultistateLabelMorph.class/instance/as yet unclassified/disabledColor.st R Morphic-Widgets-Basic.package/MultistateLabelMorph.class/instance/as yet unclassified/disabledColor_.st R Morphic-Widgets-Basic.package/MultistateLabelMorph.class/instance/as yet unclassified/drawOn_.st R Morphic-Widgets-Basic.package/MultistateLabelMorph.class/instance/as yet unclassified/initWithContents_font_emphasis_.st R Morphic-Widgets-Basic.package/MultistateLabelMorph.class/instance/as yet unclassified/interactionState_.st R Morphic-Widgets-Basic.package/MultistateLabelMorph.class/instance/as yet unclassified/mouseOverColor_.st R Morphic-Widgets-Basic.package/MultistateLabelMorph.class/instance/as yet unclassified/normalColor_.st R Morphic-Widgets-Basic.package/MultistateLabelMorph.class/instance/as yet unclassified/pressedColor_.st R Morphic-Widgets-Basic.package/MultistateLabelMorph.class/instance/as yet unclassified/selectedColor_.st R Morphic-Widgets-Basic.package/MultistateLabelMorph.class/instance/as yet unclassified/selectedDisabledColor_.st R Morphic-Widgets-Basic.package/MultistateLabelMorph.class/instance/as yet unclassified/selectedMouseOverColor_.st R Morphic-Widgets-Basic.package/MultistateLabelMorph.class/instance/as yet unclassified/selectedPressedColor_.st R Morphic-Widgets-Basic.package/MultistateLabelMorph.class/instance/initialization/initialize.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50381.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50382.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50381.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50382.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50382 16730 Should sync back Rubric https://pharo.fogbugz.com/f/cases/16730 16765 Typo https://pharo.fogbugz.com/f/cases/16765 16766 Deprecate unreferenced/unused MultistateLabelMorph https://pharo.fogbugz.com/f/cases/16766 http://files.pharo.org/image/50/50382.zip

Oct. 12, 2015

Re: [Pharo-dev] hello

by ClÃ©ment Bera

2015-10-12 15:33 GMT+02:00 phil(a)highoctane.be <phil(a)highoctane.be>: > > On Mon, Oct 12, 2015 at 3:20 PM, Thierry Goubier < > thierry.goubier(a)gmail.com> wrote: > >> Hi SebastiÃ n, >> >> 2015-10-12 13:53 GMT+02:00 SebastiÃ¡n Krynski <skrynski(a)gmail.com>: >> >>> Hello my name is SebastiÃ¡n Krynski from Buenos Aires, Argentina. >>> Just writing to let you know that I'm starting to work on adding an >>> atomic swap operator in Pharo , guaranteed not to be interrupted by the VM. >>> The operator will be used this way: >>> >>> a :=: b >>> >>> meaning 'swap variable a with variable b'. >>> >> >> Why a cryptic, special syntax? The compiler could inline an explicit >> message send which would make the intent clear. >> > > See previous discussions about <=> indeed. > >> >> a atomicSwapWith: b. >> >> Well, anyway, the compiler has to do something special there. >> >> Could we have something like... >> >> [ | temp | >> temp := a. >> a := b. >> b := a ] atomic >> >> ? Would a compiler be able to merge that in a swap instruction? And make >> another type of processing for a different code inside the block? >> > > We have Mutex>>critical: aBlock etc. > > Why not Atomic>>do: aBlock ? > Honestly this block followed by atomic is very confusing IMO. That means that the compiler has to raise an error if it did not succeed to compile the block in a single cpu instruction, i.e., a single bytecode that compiles to a single cpu instruction. For example: [ | temp | temp := a. a := b. b := a. self foo ] atomic has to raise a compilation error as the block cannot be compiled in a single instruction. Overall very few instructions in specific order can be compiled in a such a block. Atomic>>#do: can work but the argument block needs to be compiled in a single instruction so the bytecode compiler has to aware of the syntax based on the selector anyway. For example, in: anAtomic do: [ | temp | temp := a. a := b. b := a ] then the compiler has to compile the block specifically to have single instruction, even if the call to anAtomic is done in the runtime. On the other hand a new special selector as #atomicSwapWith:, in a similar way to #ifTrue:ifFalse:, is definitely doable and easy to implement. If you think it's more readable then it's the way to go. It does not extend the syntax so I think it can be done like that for the experiment as it is simpler to implement. > > Would indeed be more readable than :=: > > Phil > >> >> >>> In order to do this I will be modifying the VM and the Compiler . >>> >>> Good luck. This is an important step. >> >> >>> I'm working under the direction of INRIA and Gabriela ArÃ©valo. >>> >> >> Welcome! >> >> Thierry >> > >

Oct. 12, 2015

Re: [Pharo-dev] Problems with a large block

by Henrik Johansen

> On 12 Oct 2015, at 3:43 , Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > >> On 10 Oct 2015, at 10:05 , Nicolai Hess <nicolaihess(a)web.de <mailto:nicolaihess@web.de>> wrote: >> >> >> >> 2015-10-08 23:45 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com <mailto:eliot.miranda@gmail.com>>: >> Hi Nicolai, >> >> On Thu, Oct 8, 2015 at 2:27 PM, Nicolai Hess <nicolaihess(a)web.de <mailto:nicolaihess@web.de>> wrote: >> Hello Eliot, and thanks for your time. >> >> >> In our (pharo) implementation for sourceNodeForPC, we start at the AST-Node of >> the compiled method, get the IR (IntermediateRepresentation) and scan this sequence of IRNodes >> until we finally find that one, that maps to the bytecode of the closure creation code (this should be a IRPushClosureCopy). >> The problem is now, we don't find (always) the right IRNode, and it depens on the number of local temps, if this is > 3 we don't hit the right one. >> >> That's very strange. Can you construct a synthetic example of two simple blocks, one with three temps and and one with four temps and show me the difference in the byte code? >> >> >> [ :x | | a b c | a:=b:=c:=x ] "calling #sourceNode gives a RBBlockNode - ok" >> Bytecode >> 13 <8F 01 00 0B> closureNumCopied: 0 numArgs: 1 bytes 17 to 27 >> 17 <73> pushConstant: nil >> 18 <73> pushConstant: nil >> 19 <73> pushConstant: nil >> 20 <10> pushTemp: 0 >> 21 <81 43> storeIntoTemp: 3 >> 23 <81 42> storeIntoTemp: 2 >> 25 <81 41> storeIntoTemp: 1 >> 27 <7D> blockReturn >> 28 <7C> returnTop >> >> >> [ :x | | a b c d | a:=b:=c:=d:=x ] "calling #sourceNode gives a RBMethodNode - not ok" >> Bytecode >> 13 <8F 01 00 0E> closureNumCopied: 0 numArgs: 1 bytes 17 to 30 >> 17 <73> pushConstant: nil >> 18 <73> pushConstant: nil >> 19 <73> pushConstant: nil >> 20 <73> pushConstant: nil >> 21 <10> pushTemp: 0 >> 22 <81 44> storeIntoTemp: 4 >> 24 <81 43> storeIntoTemp: 3 >> 26 <81 42> storeIntoTemp: 2 >> 28 <81 41> storeIntoTemp: 1 >> 30 <7D> blockReturn >> 31 <7C> returnTop >> >> As I wrote above, in Pharo, to get the sourceNode we try to find the push closure bytecode from "startpc - 1" by traversing >> the IR and try to get the IRNode with matching "bytecodeOffset". The bytecodeOffsets for the above blocks: >> >> [ :x | | a b c | a:=b:=c:=x ] >> "bytecodeOffset -> IR" >> 19->pushClosureCopyCopiedValues: #() args: #(#x) >> 28->returnTop >> 20->pushTemp: #x >> 22->storeTemp: #c >> 24->storeTemp: #b >> 26->storeTemp: #a >> 27->blockReturnTop >> >> [ :x | | a b c d | a:=b:=c:=d:=x ] >> "bytecodeOffset -> IR" >> 20->pushClosureCopyCopiedValues: #() args: #(#x) >> 31->returnTop >> 21->pushTemp: #x >> 23->storeTemp: #d >> 25->storeTemp: #c >> 27->storeTemp: #b >> 29->storeTemp: #a >> 30->blockReturnTop >> >> Both blocks don't have a bytecodeOffset matching the bytecode of the pushclosure (13), but we start the search from "startpc - 1" (= 16) >> and do a loop from 0 to -3 (because bytecodes can have a length of 1,2 or 4) >> For the first block, this works >> bytecodeOffset 19 = 16 - (-3) >> For the second block this does not work, somehow the bytecodeoffset value depends on the number of local temps. And for the >> second block this is one greater. >> >> >> >> >> And my interpretation was, the IRPushClosureCopy node has the wrong "bytecode offset" (whatever this is). The bytecodeOffset value (somehow) >> depends on the number of local temps, but maybe this is right (for whatever this is used) and we are just using it wrong for in this situation. >> >> So you need to ask Marcus how to interpret bytecodeOffset. The thing is, it should be simple. One has: >> >> BlockCreationBytecode >> any number of pushConstant: nil's (0 to N) >> first byte code in block >> last bytecode in block (always a blockReturnTop) >> >> and a block's startup is always that of the byte immediately following the BlockCreationBytecode. So if the byte code offset is somehow the span of the "any number of pushConstant: nil's (0 to N)" then there's a bug in the IR somewhere when the number of temps is > 3. But if that's not what it means then, well, I don't know what the problem is. >> > > For some reason, bytecodeOffset is the *last* byte associated with IR. > This makes little sense to me, the main use seems to be to get correct offsets for different instructions in an IR sequence. > Since block IR includes temp initialization bytes, the offset is 5. > > Changing the code to record *starting* offset of an IRNode in IRSequence, by: > mapBytesTo: instr > "Associate the current byte offset with instr. We fix this later to have the correct offset, > see #bytecodes" > instrMap add: instr -> (bytes size + 1) > > and mapping bytes *before* visiting node in the IRTranslatorV2: > visitInstruction: instr > gen mapBytesTo: instr. > self visitNode: instr. > > and the same in visitPushClosureCopy: closure > closure copiedValues do: [:name | > gen mapBytesTo: closure. > gen pushTemp: (self currentScope indexForVarNamed: name). > > ]. > --snip-- Hupps, the pushing of copiedValues are not part of the closure bytecode, so that needs to be closure copiedValues do: [:name | gen pushTemp: (self currentScope indexForVarNamed: name). ]. gen mapBytesTo: closure. Thanks testBlockAndContextSourceNode! After a recompile of the test methods in case of cached IR (and offsets) (RPackageOrganizer default packageNamed: 'OpalCompiler-Tests') classes do:#recompile All (existing) tests are green with the attached change set (where haltOnce's were removed too), at least in the almost-release version of Pharo4 I tested in. Cheers, Henry

Oct. 12, 2015

Re: [Pharo-dev] Integer>>#putOn:

by Esteban Lorenzano

> On 12 Oct 2015, at 14:39, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> >> On 12 Oct 2015, at 14:26, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: >> >> Hi, >> >> I just spotted this: >> >> >> Integer>>#putOn: aStream >> >> (aStream isBinary ifTrue: [ self asByteArray ] ifFalse: [ self asString]) putOn: aStream > > IMO, this is not good, implicit (and inefficient) conversions are being done. Why ? I donât knowâ¦ I was just passing through :) > > What is the exact contract of #putOn: anyway ? > > If the result should really depend on the argument, double dispatch might be better. > >> It does not look so bad at the begining, butâ¦ if I do: >> >> ByteArray streamContents: [ :s | 42 putOn: s ] >> >> I got an infinite loop. >> >> I know, it does not look as a very typical case, butâ¦ if Iâm writing to a Socket and I want to use >> >> mySocket << 255 âIACâ, thatâs exactly what will happen :( >> >> If I redefine it as: >> >> Integer>>#putOn: aStream >> aStream isBinary ifFalse: [ >> self asString putOn: aStream. >> ^ self ]. >> self asByteArray do: [ :each | aStream nextPut: each ] >> >> then is okâ¦ >> >> Would that be a good change? > > Yeah that looks about right, still weird, but no weirder than before ;-) I submitted a fix, still ugly but wellâ¦ at least it avoids the infinite loop :P > >> Esteban

Oct. 12, 2015

Re: [Pharo-dev] seg fault on Ubuntu when launching

by Robert Withers

That is precisely what I did. Here's the screenshot attached. My image 'warren4.1' is a Pharo 4.0 image. Robert On 10/12/2015 09:52 AM, phil(a)highoctane.be wrote: > I used these instructions: > > http://pharo.org/gnu-linux-installation#ubuntu-ppa-headless-vm > > Can you post a screenshot showing what you launch from the launcher? > > Phil > > On Mon, Oct 12, 2015 at 3:41 PM, Robert Withers > <robert.w.withers(a)gmail.com <mailto:robert.w.withers@gmail.com>> wrote: > > I am brand new to Ubuntu, as well. I am pretty lost with versions. > How would I check? I installed whatever came with apt-get. > > Oh, I tried a image/changes for the launcher dated 2015.09.14, if > that helps. It segfaulted. > > - Robert > > > On 10/12/2015 09:36 AM, phil(a)highoctane.be > <mailto:phil@highoctane.be> wrote: >> I am using Ubuntu 14.04 and Pharo Launcher without issues. >> >> Which image ? 4.0? >> >> Phil >> >> On Mon, Oct 12, 2015 at 3:27 PM, Robert Withers >> <robert.w.withers(a)gmail.com <mailto:robert.w.withers@gmail.com>> >> wrote: >> >> Hello, I am new to Pharo and just getting into it. >> >> I have Ubuntu and used PPA to install Pharo. The launcher is >> failing with a segfault crash.dmp when trying to launch. It >> is the UnixOSProcessAccessor>>forkAndExec... that is >> segaulting. I looked in /usr/lib/pharo-vm and do not see a >> UnixOSProcess plugin. Is it internal? >> >> I am able to launch an image from outside the launcher. >> >> -- >> thanks, >> Robert >> >> >> > > -- > thanks, > Robert > > -- thanks, Robert

Oct. 12, 2015

Re: [Pharo-dev] seg fault on Ubuntu when launching

by phil＠highoctane.be

I used these instructions: http://pharo.org/gnu-linux-installation#ubuntu-ppa-headless-vm Can you post a screenshot showing what you launch from the launcher? Phil On Mon, Oct 12, 2015 at 3:41 PM, Robert Withers <robert.w.withers(a)gmail.com> wrote: > I am brand new to Ubuntu, as well. I am pretty lost with versions. How > would I check? I installed whatever came with apt-get. > > Oh, I tried a image/changes for the launcher dated 2015.09.14, if that > helps. It segfaulted. > > - Robert > > > On 10/12/2015 09:36 AM, phil(a)highoctane.be wrote: > > I am using Ubuntu 14.04 and Pharo Launcher without issues. > > Which image ? 4.0? > > Phil > > On Mon, Oct 12, 2015 at 3:27 PM, Robert Withers < > robert.w.withers(a)gmail.com> wrote: > >> Hello, I am new to Pharo and just getting into it. >> >> I have Ubuntu and used PPA to install Pharo. The launcher is failing with >> a segfault crash.dmp when trying to launch. It is the >> UnixOSProcessAccessor>>forkAndExec... that is segaulting. I looked in >> /usr/lib/pharo-vm and do not see a UnixOSProcess plugin. Is it internal? >> >> I am able to launch an image from outside the launcher. >> >> -- >> thanks, >> Robert >> >> >> > > -- > thanks, > Robert > >

Oct. 12, 2015

Re: [Pharo-dev] [ANN] Cupboard inspector for Teapot

by phil＠highoctane.be

Very nice! Will come handy for me next monday (hackathon time). Phil On Mon, Oct 12, 2015 at 3:37 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > Hi, > > I took a few minutes to add a custom inspector tool ("Cupboard") to > Teapot showing all the available teapots. The tool is accessible from the > Tool menu right after loading "Teapot" and allows get an overview on > running teapots. > If you teapot has dynamic routes they will be shown as well. See screenshot > attached. > > You can also start/stop a Teapot or add a new one serving static > contents from a selected directory. > > Also catalog messages were added to the ConfigurationOfTeapot and the > NeoJSON repo in the dependencies was fixed. > > Just get the lates stable version: > > Gofer it > smalltalkhubUser: 'zeroflag' project: 'Teapot'; > configuration; > loadStable. > > or directly load from ConfigBrowser (Pharo 4) or CatalogBrowser/Spotter > (Pharo 5) > in a fresh image. > > > If you want to quickly serve a (static) webpage from Pharo > ========================================================== > Create a web directory and HTML page > - use "Tools" -> "File Browser" > - create a directory "www" using "Add new directory", navigate to it > - create a new file "index.html" using "Add new file", edit it and > accept the changes > > Serve it from Pharo > - load Teapot in a fresh image > - open "Tools" -> "Teapot" > - click on the server icon on the right to create a new static server > - accept the default port 80 or enter a new one > - select the directory > > Point your browser to http://localhost:80 > > If you want to quickly server (dynamic) content from Pharo: > =========================================================== > - use one of the examples on http://smalltalkhub.com/#!/~zeroflag/Teapot > Note that the dynamic routes are shown in the new tool > > Tip: if you like use "Mustache" template library to mix HTML content > (like Bootstrap templates, Material design templates or other > with your Pharo server objects to serve pages) > > Have fun > T.

Oct. 12, 2015