March 2018 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Yet another Pharo in docker

by Sean P. DeNigris

Herby VojÄÃk wrote > https://hub.docker.com/r/herbysk/pharo/ How are the images built from https://lolg.it/herby/pharo-docker? ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

March 3, 2018

Re: [Pharo-users] Yet another Pharo in docker

by Sean P. DeNigris

Herby VojÄÃk wrote > https://hub.docker.com/r/herbysk/pharo/ Cool! I noticed the following [1]: ln -s \ `/sbin/ldconfig -p | sed -e 's|[^/]*||' | grep sqlite3` \ `find . -type f -name SqueakSSL.so -print0 | xargs -0 dirname`/sqlite3.so What does it do? Answer from Herby in private mail: fixes linux lib lookup problem in ffi, which I discussed on ML or in bug tracker few months ago. FFI was not able to localize sqlite, so the fix chosen was to find its location and symlink it to pharo directory with good name so it then finds it (it is mentioned in docker desc "fixes sqlite"). 1. https://lolg.it/herby/pharo-docker/src/master/61_32/Dockerfile ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

March 3, 2018

Re: [Pharo-users] Ever growing image

by Benoit St-Jean

On a side note, being a long-time VW & VAST user, I've always felt the Image Stripper & Runtime Packager did a fairly good job at removing crap from the resulting image.Â I don't recall ready anything substantial comparing the Pharo way (bootstrapping from a minimal image and adding stuff) to the VW & VAST way (removing unreferenced stuff) but this would definitely be an interesting topic to read about. ----------------- BenoÃ®t St-Jean Yahoo! Messenger: bstjean Twitter: @BenLeChialeux Pinterest: benoitstjean Instagram: Chef_Benito IRC: lamneth Blogue: endormitoire.wordpress.com "A standpoint is an intellectual horizon of radius zero".Â (A. Einstein) On Saturday, March 3, 2018, 9:22:06 AM EST, Hilaire <hilaire(a)drgeo.eu> wrote: Le 02/03/2018 Ã 22:52, Marcus Denker a Ã©critÂ : > > we should again do some analysis where space is goingâ¦ the Pharo7 download > is now 38MB (the image, decompressed). Situation improved :) Remember P3 was just above 20 MB

March 3, 2018

Re: [Pharo-users] Ever growing image

by Hilaire

Le 02/03/2018 Ã 22:52, Marcus Denker a Ã©critÂ : > > we should again do some analysis where space is goingâ¦ the Pharo7 download > is now 38MB (the image, decompressed). Situation improved :) Remember P3 was just above 20 MB > > There are things to look for: > > 1) wasted space due to not thinking about memory and just âhaving itâ. > > Of course some of it are things like duplications (we now have 2 > browsers, 2 inspectors, > 2 debuggersâ¦ time to clean up a bitâ¦). > > Then every test we add takes space, every âhelp topicâ, every feature... It looks like this topic comes and goes since 20 years: new features added, image growth then/or it becomes hard to unload ; on Squeak then now with Pharo at a much higher rate. We all know about the right approach (GNU Smalltalk, CUIS Smalltalk), but it is not the road chosen with Pharo and it is becoming extremely uninteresting for me to code on DrGeo now. So far I fell ashame to ship end user application with a 50MB DrGeo image, knowing only 10% has purpose related to DrGeo domain. When situation improves, motivation may come back. For this same reason and other, I turned to Python for a planed programming course to mid high school students. > > But of course sometimes being able to invest memory into a better > system can be important, too. > Not all growth in memory is negativ if you can afford it. > > I always like to play the game to think âwhat would they have done in > 1978 if they had this amount > of memory in even a $5 machine?" Of course one can go very quickly in > the wrong direction, but Very likely not that much. May be the wonders came because of the hight constraints. > nevertheless: sometimes it is really worth to think about âspending > memoryâ to buy abstraction. > (especially a there are counter measuresâ¦ we under-utilise both > compression and disk storage) Helps could (should?) be file based, and maybe other stuff I don't know. How the image is considered in the Pharo team?Â A kind of sacred place, where stuff are added following a few guidelines (you will not duplicate features but replace/imprive/whatever -- aka funny shortcut mess, you will make your code unloadable, etc...) or just like a forum where teams add feature according to projects or vision. Sorry to discuss these topics again, really don't want but still need to share a few thoughts. > > 2) wasted space that is just not needed. e.g. there is issue > https://pharo.fogbugz.com/f/cases/21172/ > Â Â That we have some huge strings to init unicode. Do we need them? > > 3) Memory leaks, bit they are more for the case when the system is > running for a while. > -- Dr. Geo http://drgeo.eu

March 3, 2018

Re: [Pharo-users] depending on a group of a BaselineOf

by Peter UhnÃ¡k

Thank you all... I guess I must have been doing something wrong, because I've tried `loads:` before. But it is working now. Thanks! Peter On Tue, Feb 27, 2018 at 11:56 AM, Jupiter Jones <jupiter.jones(a)mail.com> wrote: > (I hope this isnât posted twice - I accidentally sent it from an address > that wasnât subscribed so this is a repost - apologies) > > Hi Peter, > > Iâve never had to use the provides: method even with fairly complex > Baselines. > > This is an example of the kind of thing Iâve been using: > > baseline: spec > <baseline> > > spec for #common do: [ > spec > âDependency on project with BaselineOf" > baseline: 'Seaside3' with: [ > spec > loads: #('Core' 'Development' 'Zinc'); > repository: 'github://SeasideSt/Seaside:master/repository' ]; > âDependency on project with ConfigurationOf (note the version)â > configuration: âMagritte3â with: [ > spec > versionString: '3.5.2'; > repository: 'http://www.smalltalkhub.com/ > mc/Magritte/Magritte3/main' ]; > > âNow define my project packagesâ > package: 'MyProject-Model' with: [ > spec requires: #(âMagritte3') ]; > package: âMyProject-UI' with: [ > spec requires: #('MyProject-Modelâ 'Seaside') ]; > package: âMyProject-Tests-Modelâ with: [ > spec requires: #('MyProject-Modelâ) ]; > > âNow define groups for convenience. Groups can load dependencies, > packages, or other groupsâ > group: âModel' with: #(âMyProject-Modelâ); > group: âUI' with: #(âMyProject-UIâ); > group: âTestsâ with: #(âMyProject-Testsâ) > > âMetacello will load the default group unless you specify otherwise" > group: âdefaultâ with: #(Modelâ âUIâ); > > âOther possible convenience groupsâ > group: âDevelopmentâ with: #(Modelâ âUIâ âTestsâ); > group: âProductionâ with: #(Modelâ âUIâ) > ] > > > Then you can load groups like: > > Metacello new > baseline: âMyProjectâ; > repository: âgithub://MyGitHubUser/MyProject:master/repository' > loads: #(âDevelopmentâ); > load > > Hope this helps :) > > Cheers, > > Jupiter > > On 27 Feb 2018, at 9:30 am, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > Hi, > > I'm trying to define a dependency on a group of BaselineOf. > > specifically #core of github://pharo-graphics/Bloc/src. > > I've looked at this https://github.com/Metacello/ > metacello/blob/master/docs/GettingStartedWithGitHub.md#create-baseline > > which recommends using import:provides: > > baseline: spec > <baseline> > > spec for: #common do: [ > "Sample defines the group 'default'" > spec baseline: 'Sample' with: [ > spec repository: 'github://dalehenrich/Sample:master' ]. > spec import: 'Sample' provides: #('default'). > > "OtherSample *also* defines the group 'default'" > spec baseline: 'OtherSample' with: [ > spec repository: 'github://dalehenrich/Sample:master' ]. > spec import: 'OtherSample' provides: #('default'). > > "'default' can now be successfully resolved, even though both projects define the same name" > spec package: 'OtherProject-Core with: [ spec requires: 'default' ] ]. > > > However this code is confusing... both Sample & OtherSample provide > `default`, so on what does `OtherProject-Core` actually depend? > > In the examples here https://github.com/Metacello/ > metacello/blob/master/docs/LockCommandReference.md there are groups with > the name of the project in them ('External Core' 'External Tests'), but > this won't work if I don't control the project I am loading, plus it feels > like a hackish workaround. > > Also, can it be unified with the way ConfigurationOf works? > > > Thanks, > Peter > > >

March 3, 2018

my mistake on Spec?

by Yuriy Babah

Hi! I'm trying to write GUI element with Spec, Pharo6.1x64 on Linux. Do according to the SpecBooklet. Finished the fragment, and try do: ui := GUI_ListCourtCase new openWithSpec . -> #value was sent to nil. I look in a debugger and: *openWithSpecLayout: aSpec "Build the widget using the spec name provided as argument and display it into a window" (window value notNil and: [ self needRebuild not ]) ifTrue: [ "window != nil" window value rebuildWithSpecLayout: aSpec ] ifFalse: [ "If value = Nil --> send him a message ???" window value: (self defaultWindowModelClass new model: self). window value openWithSpecLayout: aSpec. self takeKeyboardFocus ]. ^ window value*

March 3, 2018

Re: [Pharo-users] HMAC-SHA512

by Ben Coman

On 3 March 2018 at 02:22, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: > Hi > > 2018-03-02 11:24 GMT-03:00 Esteban A. Maringolo <emaringolo(a)gmail.com>: > > 2018-03-02 8:54 GMT-03:00 Ben Coman <btc(a)openinworld.com>: > > > >> On 2 March 2018 at 10:43, Esteban A. Maringolo <emaringolo(a)gmail.com> > wrote: > > > >>> So after all this what's the recommended way to use HMAC-SHA512 in > Pharo > >>> 6? > > > >> Libsodium installation instructions... > >> https://github.com/Traadh/bittrex > > > > Why did you create BittrexLibsodium library wrapper instead of a > > plain Libsodium wrapper like the one at > > http://smalltalkhub.com/#!/~tonyg/Crypto-Nacl/ ? > If that is the one available from the Pharo Catalog, when I tried it, it used a different api than the libsodium library supplied by Ubuntu 16.04. It makes this call out... crypto_hash_sha512_ref() but Ubuntu libsodium library did not export that, but instead... crypto_hash_sha512() I failed to track down the implications of the "_ref", and at that time Crypto-Nacl did not supply a 64-bit library, so a single FFI matching the system supplied libsodium library was easier. Also as a minor policy, I prefer to use the system library than one compiled by a third-party. cheers -ben > > > > > I inspected the Nacl library and it provides the functions: > > crypto_auth_hmacsha256 > crypto_auth_hmacsha256_bytes > crypto_auth_hmacsha256_keybytes > crypto_auth_hmacsha256_primitive > crypto_auth_hmacsha256_ref > crypto_auth_hmacsha256_ref_verify > crypto_auth_hmacsha256_verify > crypto_auth_hmacsha512256 > crypto_auth_hmacsha512256_bytes > crypto_auth_hmacsha512256_keybytes > crypto_auth_hmacsha512256_primitive > crypto_auth_hmacsha512256_ref > crypto_auth_hmacsha512256_ref_verify > crypto_auth_hmacsha512256_verify > > I've also followed the Ben's example in Nacl but the output is truncated > > | data message output key expected | > data := 'Hi There' . > key := (ByteArray readHexFrom: > '0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b', > '0b0b0b0b') extendedToSize: 32. > expected := ByteArray readHexFrom: > '87aa7cdea5ef619d4ff0b4241a1d6cb0', > '2379f4e2ce4ec2787ad0b30545e17cde', > 'daa833b7d6b8a702038b274eaea3f4e4', > 'be9d914eeb61f1702e696c203a126854'. > output := ByteArray new: 64. > Nacl apiCryptoAuthHMAC512: output > message: data > messageLength: data size > key: key. > output > > Just off the top of my head, should the following method properly be named apiCryptoAuthHMAC512256:message:messageLength:key: to match the library function its calling? > Nacl class>>apiCryptoAuthHMAC512: c message: m messageLength: mlen key: > key > ^ self > ffiCall: #(long crypto_auth_hmacsha512256(byte * c, byte * m, > ulonglong mlen, byte * key)) > module: 'libsodium'. > > Ben do you know what could be happening here? > > By how much is it truncated? Perhaps half? https://dirvine.github.io/data_chain/master///rust_sodium_sys/constant.cryp… https://dirvine.github.io/data_chain/master///rust_sodium_sys/constant.cryp… cheers -ben

March 3, 2018

Re: [Pharo-users] Ever growing image

by Marcus Denker

> On 2 Mar 2018, at 21:31, Hilaire <hilaire(a)drgeo.eu> wrote: > > Ah, you are right it is a 32bits image. > > My bad, Dr.Geo does not build with 64bits image Pharo7.0-64bit-52a28a8 > > ConfigurationOfDrGeo class methodsFor: 'metacelUnmatched ' in string literal. -> > > May be should try a more recent P7 64 bits image > > > Note: 52 MB is an overlarge image size for me (down 50% will be nice) > we should again do some analysis where space is goingâ¦ the Pharo7 download is now 38MB (the image, decompressed). There are things to look for: 1) wasted space due to not thinking about memory and just âhaving itâ. Of course some of it are things like duplications (we now have 2 browsers, 2 inspectors, 2 debuggersâ¦ time to clean up a bitâ¦). Then every test we add takes space, every âhelp topicâ, every feature... But of course sometimes being able to invest memory into a better system can be important, too. Not all growth in memory is negativ if you can afford it. I always like to play the game to think âwhat would they have done in 1978 if they had this amount of memory in even a $5 machine?" Of course one can go very quickly in the wrong direction, but nevertheless: sometimes it is really worth to think about âspending memoryâ to buy abstraction. (especially a there are counter measuresâ¦ we under-utilise both compression and disk storage) 2) wasted space that is just not needed. e.g. there is issue https://pharo.fogbugz.com/f/cases/21172/ <https://pharo.fogbugz.com/f/cases/21172/> That we have some huge strings to init unicode. Do we need them? 3) Memory leaks, bit they are more for the case when the system is running for a while. Marcus

March 2, 2018

Re: [Pharo-users] Ever growing image

by Hilaire

Ah, you are right it is a 32bits image. My bad, Dr.Geo does not build with 64bits image Pharo7.0-64bit-52a28a8 ConfigurationOfDrGeo class methodsFor: 'metacelUnmatched ' in string literal. -> May be should try a more recent P7 64 bits image Note: 52 MB is an overlarge image size for me (down 50% will be nice) Hilaire Le 02/03/2018 Ã 16:41, tesonep(a)gmail.com a Ã©critÂ : > Hi Hilaire, is it possible that is the wrong image? > This is a 32bits image, and it is around 52 MB, quite similar to the > Pharo base image. > -- Dr. Geo http://drgeo.eu

March 2, 2018

Re: [Pharo-users] casting to subclass

by Esteban A. Maringolo

"Castings" are aliens in the Smalltalk world, although there is a #become*: method family, I would discourage you from using it as an alternative unless you really need to do it. If your use case is that concrete, I'd do something like: `ILHTMLBuilderElement fromXMLElement: anXMLElement` Then all subclasses of `ILHTMLBuilderElement` will know what to look and what to omit from the `XMLElement` parameter. Regards! Esteban A. Maringolo 2018-03-02 17:08 GMT-03:00 Stephan Eggermont <stephan(a)stack.nl>: > Siemen Baader <siemenbaader(a)gmail.com> wrote: >> >> What else could I do, apart from removing the element from its tree, >> creating a new (subclass) instance and then putting this element in place >> of the old one? Some #perform or `super` magic..? > > Use composition? Generate accessing code where necessary. > Is this very performance critical code? > > Stephan > > >

March 2, 2018