Re: [Pharo-users] StCAD is open source

[askoh]

Hi:

I am preparing to port StCAD from VisualWorks to Pharo. Please advise how
this can be done most efficiently. I am not familiar with Pharo GUI
development.

StCAD uses Jun which uses OpenGL and GLUT. I am open to using newer graphics
frameworks and CUDA or OpenCL.

Thanks,
Aik-Siong Koh



--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Re: [Pharo-users] how to rewrite this to use a stream

[Richard O'Keefe]

Starting from the top:\
(0) It's not *wrong* to start a selector with a capital letter, but
it is certainly unusual.
(1) Intention-revealing names are good.  That's why this name is bad.
It does not *delete* anything.
(2) The comment again says "delete" but nothing is deleted.  Comments
that mislead are worse than no comments.
(3) An issue I have seen over and over in student code (in other
programming languages) is writing regular expressions as string
literals where they are used, so that every time you try a match
the regular expression gets recompiled, over and over again.
You're not exactly doing that, but you *are* rebuilding patterns
over and over again.  It would make more sense to hold a
forbiddenPatterns collection.
(4) You are saying "(coll reject: [..test..]) notEmpty", building an
entire collection just to ask whether it has any members.  What
you want to know is "are there any elements of coll that do not
satisfy the test", which can be expressed as
(coll allSatisfy: [..test..]) not.  (Sadly there is no
#notAllSatisfy:, although #notAnySatisfy: *does* exist under the
name #noneSatisfy:.
(5) #match: is a highly risky way to look for a substring.  What if
you want to look for a literal # or * ?  What if you need to
look for 'Boring' but not 'boring'?  ("Boring" is a perfectly
good surname.)
(6) You really don't need the "result" variable.

allowedWords
  "Answer those words which do not contain any forbiddenWord
   as a substring."
  ^words select: [:each |
 forbiddenWords noneSatisfy: [:forbidden |
<>]]

(7) You can find out how to do the <> by looking at the methods
for String.  You will find several candidate methods.
(8) Of course, if there are W words and F forbidden words, in the
worst case you'll do W*F substring inclusion tests.  This is not
good.  "Multiple pattern matching" is a much-studied problem,
see for example Wu and Manber's paper

http://web.archive.org/web/20130203031412/http://www.inf.fu-berlin.de/inst/ag-bio-expired/FILES/ROOT/Teaching/Lectures/WS0506/WeiterfThemenBioinf/papers/FastAlgorithmMultiPatternSearching-WuManbers-TR94.pdf
There is more recent work also.

Does anyone know whether there's a multiple pattern algorithm for
Pharo?  One could always fall back on ternary search trees...



On Fri, 14 Dec 2018 at 05:13, Roelof Wobben  wrote:

> Hello,
>
> I have this code :
>
>  FindAndDeleteWordsWithForbiddenParts
> "deletes all the words that contain forbidden parts"
>
> | result |
> result := words
> select: [ :word |
> [ (forbiddenWords reject: [ :forbidden | '*' , forbidden , '*' 
> match: word ]) isNotEmpty ]
> on: NotFound
> do: [ false ] ].
> ^ result
>
>
> but I see warnings that I have to use a stream instead of string concentation.
>
> Anyone hints how to do so ?
>
> Roelof
>
>
>

Re: [Pharo-users] Pharo 7 and Zero conf problem

[John Kimber via Pharo-users]

--- Begin Message ---

Hi, I recently installed Pharo-Launcher under Mint 19. Version 70 build 1384
seems to be running fine.

HTH, john





--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

--- End Message ---

[Pharo-users] Pharo 7 and Zero conf problem

[Vitor Medina Cruz]

Hello,

Under debian, loading

curl https://get.pharo.org/64/70+vm | bash

And then executing:

./pharo Pharo.image eval "Class allInstances"

I got:

self recordInitializationSuccess ] in LGitLibrary>>initializeLibGit2
in Block: [ self libgit2_init
BlockClosure>>on:do:
LGitLibrary>>initializeLibGit2
LGitLibrary class>>startUp:
ClassSessionHandler>>startup:
[ :each | each startup: isImageStarting ] in
WorkingSession>>runStartup: in Block: [ :each | each startup:
isImageStarting ]
[ aBlock value: each ] in [ :each |
[ aBlock value: each ]
on: Exception
do: [ :error | self errorHandler handleError: error ] ] in
WorkingSession>>runList:do: in Block: [ aBlock value: each ]
BlockClosure>>on:do:
[ :each |
[ aBlock value: each ]
on: Exception
do: [ :error | self errorHandler handleError: error ] ] in
WorkingSession>>runList:do: in Block: [ :each | ...
Array(SequenceableCollection)>>do:
WorkingSession>>runList:do:
WorkingSession>>runStartup:
WorkingSession>>start:
SessionManager>>launchSnapshot:andQuit:
[ isImageStarting := self launchSnapshot: save andQuit: quit.
wait signal ] in SessionManager>>snapshot:andQuit: in Block: [
isImageStarting := self launchSnapshot: save and...etc...
[ self value.
Processor terminateActive ] in BlockClosure>>newProcess in Block: [
self value*#()*


If I use pharo 6 this error don't happened and I got *#()*

Can I ignore this error? Should I use Pharo 6? Something missed?

Regards,
Vitor


Livre
de vírus. www.avg.com
.
<#m_5683544748734822669_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Re: [Pharo-users] Agile Artificial Intelligence book

[Alexandre Bergel via Pharo-users]

--- Begin Message ---
Hi!

Thanks for having spotted it. 
Code for the first chapters can be downloaded using:
Metacello new
  baseline: 'NeuralNetwork';
  repository: 'github://AgileArtificialIntelligence/PharoSourceCode/src' ;
  load.

But note that the code is not officially released. We will package it better…

Cheers,
Alexandre
-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.



> On Dec 13, 2018, at 3:35 PM, mldavis99  wrote:
> 
> Hi, the Book so far is great, I am looking forward to more.  However, when I
> try to load the code with: 
> Metacello new
>  package: 'NeuralNetwork';
>  repository: 'github://AgileArtificialIntelligence/PharoSourceCode/src' ;
>  load.
> Both Pharo 6.1 stable and 7 Development Version do not understand:  package: 
> When I dig into it a bit this message is implemented in an abstract method
> of Metacello which does not appear to be in Metacello hierarchy??  What did
> I miss?  
> mike
> 
> 
> 
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
> 

--- End Message ---

Re: [Pharo-users] Problem loading seaside with Zinc

[Vitor Medina Cruz]

Oh yes, I thought they were woking on the change of seaside, but it is
done: https://github.com/SeasideSt/Seaside/releases/tag/v3.2.5

I put version 3.2.5 of seaside on my baseline and now it works!!!

Thanks!

On Fri, Dec 14, 2018 at 3:00 PM Cyril Ferlicot 
wrote:

> On Fri, Dec 14, 2018 at 5:55 PM Vitor Medina Cruz 
> wrote:
> >
> > Did that:
> >
> > Metacello new repository: 'github://svenvc/zinc:v3.0.1/repository';
> >   baseline: 'ZincHTTPComponents';
> >   ignoreImage;
> >   onConflict: [ :ex | ex useIncoming ];
> >   onWarning: [ :ex | Transcript crShow: ex ];
> >   silently;
> >   load;
> >   lock.
> >
> > Metacello new baseline: 'Employees';
> >   repository: 'tonel:///opt/pharo/employeesSource/pharo/';
> >   ignoreImage;
> >   onConflict: [ :ex | ex useIncoming ];
> >   onWarning: [ :ex | Transcript crShow: ex ];
> >   silently;
> >   load: #(core).
> >
> >
> > It seems it did the trick, but then I got another error:
> >
> > Fetched -> Zinc-HTTP-SvenVanCaekenberghe.1542912596 ---
> https://github.com/svenvc/zinc.git[0327c84] ---
> /opt/pharo/pharo-local/iceberg/svenvc/zinc/repository (Libgit)
> > ...RETRY->Zinc-Seaside
> > ...RETRY->Zinc-Seaside
> > ...FAILED->Zinc-Seaside[31mCould not resolve: Zinc-Seaside
> [Zinc-Seaside] in /opt/pharo/pharo-local/package-cache
> /opt/pharo/pharo-local/iceberg/SeasideSt/Seaside/repository (Libgit)
> >
> [0mMetacelloFetchingMCSpecLoader(MetacelloCommonMCSpecLoader)>>retryingResolvePackageSpecReferences:gofer:
> > [ | references nearestReference cachedReference externalReference
> mcVersion loadedVersionInfos |
> > cachedReference := nil.
> >
>
> Hi,
>
> I think I read that Seaside changed the Zinc dependency to the one on
> github. Could you retry to load it the normal way please?
>
> >
> >
>
>
> --
> Cyril Ferlicot
> https://ferlicot.fr
>
>

Re: [Pharo-users] Usage of String and FileLocator to reference files in ZipArchive (and probably other places)

[Guillermo Polito]

Hi Hans,

Sorry for the late reply.

On Sun, Nov 25, 2018 at 9:30 PM Hans-Martin  wrote:

> I found a related problem which indicates that the depreciation of
> StandardFileStream in favor of File is incomplete and probably premature:


> When a ZipArchive is written, in 7.0 it uses
> (File named: aFileName)
> writeStreamDo: [...]
> In 6.1, it uses
> StandardFileStream
> forceNewFileNamed: aFileName
> do: [...]
>

Well, the equivalent of this is:

f := File named: aFileName.
f exists ifTrue: [ f delete ].
f writeStreamDo: [...].

or

f := File named: aFileName.
f writeStreamDo: [ :stream |
   stream truncate.
   ...
].

This is, I reckon, slightly more verbose.
On the other side I personally think that "forceNewFileNamed:" is not so
useful nor general, maybe for scripting purposes.
I think that libraries (as Zip does here for example) should use that with
care, since silently overriding a file can be considered nasty :).

Besides, taking a Pharo5 image, users of forceNewFileNamed: and
forceNewFileNamed:do: are few, mostly tests.
And several of the users do override a file silently (and dangerously IMHO)
since the do not make it explicit to the user :/.
Take for example in pharo5

MIMEDocument >> saveToFile: anAbsolutePathString
FileStream forceNewFileNamed: anAbsolutePathString do: [ :str |
str binary.
str nextPutAll: (self contents) ].

or Fuel's

FLSqueakPlatform >> fileNamed: aFilename writeStreamDo: aBlock
^ FileStream
forceNewFileNamed: aFilename
do: [ :stream |
stream binary.
aBlock value: stream ]

which override the file but the method name does not indicate it. What if
the file being overwritten had important data?

which is a small but significant difference leading to corrupted zip
> archives when overwriting existing files. File does not have equivalent
> protocol to #forceNewFileNamed... so it is pretty likely that there are
> more
> bugs creeping there. Upon a cursory inspection I see that for example
> FLFileStreamStrategy will suffer from the same problem when writing to
> existing files.
>
> Is there any documentation on the reasoning of depreciating
> StandardFileStream and who is working on this? I'm really new to pharo
> development... Submitting "patches" without knowing the original design
> rationale seems not very productive.
>

I've made part of the effort myself, Sven did a bit part too, and many
other people whose names aren't coming out of the top of my head (sorry!).

Part of the migration guide is here:
https://pharoweekly.wordpress.com/2018/03/19/new-files-in-pharo-migration-guide-how-tos-and-examples/
Paver wrote another one that I cannot find right now.

There are many emails around discussing the rationale behind this. But in a
couple of words the reason was cleaning up.
We had for example the concerns of data encoding and buffering repeated
between sockets and file management.
And also this was using subclasses, which tend to explode with combinations.
We refactored this to use a decorator schema which is far more composable
and modular, and lets us reuse cross cutting concerns between memory
streams, file streams, sockets, etc.

Guille

Re: [Pharo-users] Problem loading seaside with Zinc

[Cyril Ferlicot]

On Fri, Dec 14, 2018 at 5:55 PM Vitor Medina Cruz  wrote:
>
> Did that:
>
> Metacello new repository: 'github://svenvc/zinc:v3.0.1/repository';
>   baseline: 'ZincHTTPComponents';
>   ignoreImage;
>   onConflict: [ :ex | ex useIncoming ];
>   onWarning: [ :ex | Transcript crShow: ex ];
>   silently;
>   load;
>   lock.
>
> Metacello new baseline: 'Employees';
>   repository: 'tonel:///opt/pharo/employeesSource/pharo/';
>   ignoreImage;
>   onConflict: [ :ex | ex useIncoming ];
>   onWarning: [ :ex | Transcript crShow: ex ];
>   silently;
>   load: #(core).
>
>
> It seems it did the trick, but then I got another error:
>
> Fetched -> Zinc-HTTP-SvenVanCaekenberghe.1542912596 --- 
> https://github.com/svenvc/zinc.git[0327c84] --- 
> /opt/pharo/pharo-local/iceberg/svenvc/zinc/repository (Libgit)
> ...RETRY->Zinc-Seaside
> ...RETRY->Zinc-Seaside
> ...FAILED->Zinc-Seaside[31mCould not resolve: Zinc-Seaside [Zinc-Seaside] in 
> /opt/pharo/pharo-local/package-cache 
> /opt/pharo/pharo-local/iceberg/SeasideSt/Seaside/repository (Libgit)
> [0mMetacelloFetchingMCSpecLoader(MetacelloCommonMCSpecLoader)>>retryingResolvePackageSpecReferences:gofer:
> [ | references nearestReference cachedReference externalReference mcVersion 
> loadedVersionInfos |
> cachedReference := nil.
>

Hi,

I think I read that Seaside changed the Zinc dependency to the one on
github. Could you retry to load it the normal way please?

>
>


-- 
Cyril Ferlicot
https://ferlicot.fr

Re: [Pharo-users] Problem loading seaside with Zinc

[Vitor Medina Cruz]

Did that:

Metacello new repository: 'github://svenvc/zinc:v3.0.1/repository';
  baseline: 'ZincHTTPComponents';
  ignoreImage;
  onConflict: [ :ex | ex useIncoming ];
  onWarning: [ :ex | Transcript crShow: ex ];
  silently;
  load;
  lock.

Metacello new baseline: 'Employees';
  repository: 'tonel:///opt/pharo/employeesSource/pharo/';
  ignoreImage;
  onConflict: [ :ex | ex useIncoming ];
  onWarning: [ :ex | Transcript crShow: ex ];
  silently;
  load: #(core).


It seems it did the trick, but then I got another error:

Fetched -> Zinc-HTTP-SvenVanCaekenberghe.1542912596 ---
https://github.com/svenvc/zinc.git[0327c84] ---
/opt/pharo/pharo-local/iceberg/svenvc/zinc/repository (Libgit)
...RETRY->Zinc-Seaside
...RETRY->Zinc-Seaside
...FAILED->Zinc-Seaside[31mCould not resolve: Zinc-Seaside
[Zinc-Seaside] in /opt/pharo/pharo-local/package-cache
/opt/pharo/pharo-local/iceberg/SeasideSt/Seaside/repository (Libgit)
[0mMetacelloFetchingMCSpecLoader(MetacelloCommonMCSpecLoader)>>retryingResolvePackageSpecReferences:gofer:
[ | references nearestReference cachedReference externalReference
mcVersion loadedVersionInfos |
cachedReference := nil.




On Fri, Dec 14, 2018 at 11:07 AM Vitor Medina Cruz 
wrote:

> You can use the lock API in Metacello to use the dependency you want,
>> ignoring the ones defined in the baselines.
>>
>
> You mean loading Zinc with lock before I load my project?
>
> On Wed, Dec 12, 2018 at 5:21 PM Gabriel Cotelli 
> wrote:
>
>> You can use the lock API in Metacello to use the dependency you want,
>> ignoring the ones defined in the baselines.
>>
>> On Wed, Dec 12, 2018 at 4:16 PM Vitor Medina Cruz 
>> wrote:
>>
>>> I can't depend on https://github.com/svenvc/zinc because this is a
>>> transitive dependency, my baseline depends of seaside that depends of Zinc.
>>> Is there a way to exclude Zinc dependency from Seaside so that I can force
>>> a Zinc dependency definition of my baseline?
>>>
>>> On Wed, Dec 12, 2018 at 5:08 PM Sven Van Caekenberghe 
>>> wrote:
>>>


 > On 12 Dec 2018, at 18:56, Vitor Medina Cruz 
 wrote:
 >
 > Note it is trying to reach http://mc.stfx.eu/ZincHTTPComponents,
 which don't seems to be hosting Zinc anymore. Since these are transitive
 dependencies, I tried to define Zinc in the root of my baseline, as I did
 with seaside (magritte baseline had some problem with it), but the same
 error

 Yes, that machine is partially down, the mc part will come up later,
 sorry. See my earlier message.

 The best is to depend on https://github.com/svenvc/zinc using the
 baseline.

Re: [Pharo-users] Playing with Pharo 7

[Konrad Hinsen]

On 26/11/2018 21:47, Cyril Ferlicot D. wrote:

> There is also a recent guide here:
> https://github.com/pharo-tips-and-tricks/pharo-tips-and-tricks/blob/master/General/Baselines.md
>
> I don't know if it is more beginner friendly. Feedback is welcome.

I did the ultimate test: I wrote my own Baseline using nothing but the
information from that document. It worked the first time I loaded it
into a new image!

The main open question left by the guide is how to find the URLs to your
dependencies. For packages from GitHub that is not too difficult, as the
packages' installation instructions provide the URL. But it took me a
while to figure out the URL for XMLParser, which I had installed via the
Catalog Browser. In the end I searched for XMLParser on the Web site of
smalltalkhub, where I found the URL.

Konrad.

Re: [Pharo-users] chooseExistingFileReference:extensions:path:preview returning wrong FileReference?

[Guillermo Polito]

Hi all,

I've created issue
https://pharo.fogbugz.com/f/cases/22772/chooseExistingFileReference-extensions-path-preview-returning-wrong-FileReference

And proposed a single-line fix:
https://github.com/pharo-project/pharo/pull/2075

I've tested those scenarios and it was working but some more testing would
not hurt :)
Guille

On Tue, Dec 11, 2018 at 11:15 PM Ben Coman  wrote:

> https://pharo.fogbugz.com
>
> On Wed, 12 Dec 2018 at 01:54, Arturo Zambrano 
> wrote:
>
>>  Should I report a bug? If so please send me the link to thw issue tracker
>>
>> On Tue, 11 Dec 2018, 13:05 Sven Van Caekenberghe,  wrote:
>>
>>> I confirm that this does indeed seem to be a problem, weird.
>>>
>>> > On 11 Dec 2018, at 16:53, Arturo Zambrano 
>>> wrote:
>>> >
>>> > Hi All,
>>> >  I'm  replacing a deprecated call by this:
>>> > UIManager default
>>> chooseExistingFileReference:extensions:path:preview:.
>>> >
>>> > The returned fileRefence does not point the actual file selected by
>>> the user (if the file was chosen navigating to other directories than the
>>> default).
>>> > For example:
>>> >
>>> > UIManager default chooseExistingFileReference:'Title'
>>> extensions:#('pdf') path: './' preview: nil
>>> >
>>> > 
>>> >
>>> > Inspect the result:
>>> > 
>>> >
>>> >
>>> >
>>> > It seems to be a bug, or maybe there  is any other way to call the
>>> dialog.
>>> >
>>> > Any pointer is welcome.
>>> >
>>> > TIA
>>> >
>>> >
>>> >
>>>
>>>
>>>

-- 



Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - *http://www.cnrs.fr
*


*Web:* *http://guillep.github.io* 

*Phone: *+33 06 52 70 66 13

Re: [Pharo-users] Problem loading seaside with Zinc

[Vitor Medina Cruz]

>
> You can use the lock API in Metacello to use the dependency you want,
> ignoring the ones defined in the baselines.
>

You mean loading Zinc with lock before I load my project?

On Wed, Dec 12, 2018 at 5:21 PM Gabriel Cotelli  wrote:

> You can use the lock API in Metacello to use the dependency you want,
> ignoring the ones defined in the baselines.
>
> On Wed, Dec 12, 2018 at 4:16 PM Vitor Medina Cruz 
> wrote:
>
>> I can't depend on https://github.com/svenvc/zinc because this is a
>> transitive dependency, my baseline depends of seaside that depends of Zinc.
>> Is there a way to exclude Zinc dependency from Seaside so that I can force
>> a Zinc dependency definition of my baseline?
>>
>> On Wed, Dec 12, 2018 at 5:08 PM Sven Van Caekenberghe 
>> wrote:
>>
>>>
>>>
>>> > On 12 Dec 2018, at 18:56, Vitor Medina Cruz 
>>> wrote:
>>> >
>>> > Note it is trying to reach http://mc.stfx.eu/ZincHTTPComponents,
>>> which don't seems to be hosting Zinc anymore. Since these are transitive
>>> dependencies, I tried to define Zinc in the root of my baseline, as I did
>>> with seaside (magritte baseline had some problem with it), but the same
>>> error
>>>
>>> Yes, that machine is partially down, the mc part will come up later,
>>> sorry. See my earlier message.
>>>
>>> The best is to depend on https://github.com/svenvc/zinc using the
>>> baseline.
>>>
>>>
>>>