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

[Pierce Ng]

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

Re: [Pharo-users] HMAC-SHA512

[Pierce Ng]

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] [Pharo-dev] [Issue Tracker] lots of "auto close" happening

[Tudor Girba]

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] Yet another Pharo in docker

[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

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

[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

Re: [Pharo-users] Ever growing image

[Benoit St-Jean via Pharo-users]

--- 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] Ever growing image

[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

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

[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 
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
>
>
>