Re: [Pharo-users] depending on a group of a BaselineOf
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 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 > > > 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 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 > > > 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 thoughboth 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 > > >
Re: [Pharo-users] Ever growing image
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
Re: [Pharo-users] Ever growing image
--- Begin Message --- 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 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 --- End Message ---
Re: [Pharo-users] Yet another Pharo in docker
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
Re: [Pharo-users] Yet another Pharo in docker
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
Re: [Pharo-users] [Pharo-dev] [Issue Tracker] lots of "auto close" happening
Thanks a lot for this! Doru > On Mar 2, 2018, at 7:01 PM, Marcus Denker wrote: > > Hello, > > As you might now, we automatically close issue tracker entries after 1 year > of in-activity. > Due to two factors (the job doing it not working since 1 month *and* now > being 1 year > after we started to sort issues for “has to be fixed for pharo6 yes or no”, > we enter > a period where *a lot* of issue get auto-closed. > > Everyone subscribed to the issue gets a mail and (of course!!) you should > re-opne the > issue tracker entry if the case still is relevant. > > Marcus -- www.tudorgirba.com www.feenk.com "Yesterday is a fact. Tomorrow is a possibility. Today is a challenge."
Re: [Pharo-users] HMAC-SHA512
On Fri, Mar 02, 2018 at 11:24:36AM -0300, Esteban A. Maringolo wrote: > There is a PBKDF2 package made by Udo Schneider, and seems to be > easily pluggable with a different hashing algorithm, so I'd need a > SHA512 class. OpenSSL-Pharo wraps the SHA512 in libcrypto. See LcEvpSHA512Test. https://github.com/PierceNg/OpenSSL-Pharo Pierce
Re: [Pharo-users] Yet another Pharo in docker
On Sat, Mar 03, 2018 at 09:04:59AM -0700, Sean P. DeNigris wrote: > 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, I was just about to do this Docker thing the other way, which is to bundle my own SQLite library, for these reasons: - Customize SQLite to include JSON, FTS, etc. - Yesterday I committed functionality to load SQLite extensions (so/dylib/dll files implementing SQL functions and virtual tables). I'm using a PCRE-based extension. - SQLcipher. This is in NBSQLite3, to be ported to UFFI. Pierce