- Pharo-users - lists.pharo.org

get.pharo.org broken?

by PAUL DEBRUICKER

Hi - curl https://get.pharo.org/64 | bash gives an error on MacOS X: paul@a:~/pharo/maf$ curl https://get.pharo.org/64 | bash % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 237 100 237 0 0 315 0 --:--:-- --:--:-- --:--:-- 315 bash: line 1: syntax error near unexpected token `newline' bash: line 1: `<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">' am I doing something wrong or is it broken for other people too? Thanks Paul

April 24, 2018

Re: [Pharo-users] Right repo for TaskIt and features?

by Holger Freyther

> On 24. Apr 2018, at 20:16, Santiago Bragagnolo <santiagobragagnolo(a)gmail.com> wrote: > > Hi Holger! > I respond in bold hehe. And in the reply I am back to non rich text. Let me see if I quote it correctly. > > > > On Tue, 24 Apr 2018 at 12:00 Holger Freyther <holger(a)freyther.de> wrote: > Hey! > > I wondered if somebody thought of remote task execution? > > *If you mean something else, I would need more information :). > When you do [ action ] schedule / [ action ] future, both created tasks are scheduled into the default runner. The default runner is a working pool with a default 'poolSizeMax' on 4, meaning, limit 4 processes working over the tasks. (this is a dynamic configuration, you can change it by > TKTConfiguration runner poolMaxSize: 20. ) Yes. But with more work than the workers can handle the queue will grow. Which means the (median/max) latency of the system will monotonically increase.. to the point of the entire system failing (tasks handled after the external deadlines expired, effectively no work being done). For network connected systems I like to think in terms of "back pressure" (not read more from the socket than the image can handle, eventually leading to the TCP window shrinking) and one way of doing it is to have bounded queues (and/or sleep when scheduling work). I can see multiple parts of a solution (and they have different benefits and issues): * Be able to attach a deadline to a task (e.g. see context.Context in go) * Be able to have a "blocking until queue is less than X elements" schedule (but that is difficult as one task might be scheduled during the >>#value of another task). > Are there ideas how to add remote task scheduling? Maybe use Seamless for it? > Since you speak about seamless here, i suppose two different images, doesn't matter where. > It's not a bad idea to go seamless, but i did not go through the first restriction of remote executions (if the remote image can or not execute the task and if both images share the same semantic for the execution), then i did not yet checked on which communication platform to use for it Right it would need to be homogeneous images (and care taken that the external interface remains similar enough). > Have workers connect to the scheduler? Other ideas? > what do you mean by connection to the scheduler? The workers we use do not know their pools, if that is what you mean. Let's assume scheduling a task is simple (read something from a socket) but the computation is expensive (database look-up, math, etc). Hopefully one will reach the point where one image can schedule more tasks than a single worker image can handle. At that point it could be neat to scale by just starting another image. By inverting the launch order (workers connect to the scheduler) scaling can become more easy. holger

April 24, 2018

Re: [Pharo-users] Projects using Magritte meta models

by Rafael Luque

Hi Sean, Thank you for your answer. I'm looking forward to read this project's code, however, when I try to load it following your instructions I get a ZnUnknownScheme when it is loading files from gitlab://SeanDeNigris/gitlab-smalltalk-ci:master/src: ZnUrl>>enforceKnownScheme ZnRequestLine>>uri: ZnRequest>>url: ZnClient>>url: [ client := self httpClient. client ifFail: [ :exception | (exception className beginsWith: 'Zn') ifTrue: [ MCRepositoryError signal: 'Could not access ' , self location , ': ' , exception printString ] ifFalse: [ exception pass ] ]; url: self locationWithTrailingSlash; queryAt: 'C' put: 'M;O=D'; "legacy that some servers maybe expect" get. Thank you! 2018-04-21 2:07 GMT+00:00 Sean P. DeNigris <sean(a)clipperadams.com>: > Rafael Luque wrote > > I wonder if there are other relevant projects I could study to discover > > other possible > > uses cases of Magritte. > > I use it in nearly all my personal projects, almost always via Morphic, not > Seaside. Here is a public one you can have a look at: > https://github.com/seandenigris/Small-World > > Load in Pharo 6.1 via: > Metacello new > baseline: 'SmallWorld'; > repository: 'github://seandenigris/SmallWorld:master/repository'; > onConflict: [ :ex | ex allow ]; > load. > > Browse senders of magritteDescription for classes prefixed with "Small". > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > >

April 24, 2018

Re: [Pharo-users] UFFI and autoRelease

by Esteban Lorenzano

hi, there is nothing like that and I do not recommend messing with the registry in general. butâ¦ you can always extend the classes for your use, is around FFIExternalResourceManager. cheers, Esteban > On 24 Apr 2018, at 14:48, Serge Stinckwich <serge.stinckwich(a)gmail.com> wrote: > > > I'm using autoRelease on some FFIOpaqueObject instances. > > I need to test some behavior when I delete explicitly one of these objects. âHow to remove these objects from the finalization list, in order they are not freed two times. > > Something like ignoreFinalization ? > > -- > Serge Stinckwich > UMI UMMISCO 209 (SU/IRD/UY1) > "Programs must be written for people to read, and only incidentally for machines to execute." > http://www.doesnotunderstand.org/ <http://www.doesnotunderstand.org/>

April 24, 2018

Re: [Pharo-users] SortedCollection>>reverse answers an inconsistent object in Pharo 6

by Richard O'Keefe

Let me offer a simple example. #(a a) isSortedBy: [:x :y | (x <= y) not] is false, while #(a a) isSortedBy: [:x :y | y <= x] is true. On 24 April 2018 at 02:43, Erik Stel <erik.stel(a)gmail.com> wrote: > Richard, > > Can you explain me what you mean by "sortBlock is supposed to act like > #<="? > Isn't it up to the developer to decide what the logic should be? I simply > used #<= because #> might not have been implemented for all relevant > classes, but would otherwise have chosen #> as a means to get the > 'reversal' > of #<=. > > Your solution is not resulting in the behaviour I would expect it. Adding > elements which are compared equally, but still have a different value, do > not get added in the same position. In the examples below I use > Associations, since it compares on the key only (for #<= comparison). > > Consider a regular SortedCollection with default sortBlock (set > explicitly): > | aCollection | > aCollection := SortedCollection sortBlock: [ :a :b | a <= b ]. > {#k->'Some'. #k->'Value'. #k->'Or'. #k->'Other'} do: [ :each | aCollection > add: each ]. > aCollection. > "a SortedCollection(#k->'Some' #k->'Value' #k->'Or' #k->'Other')" > > When I create a SortedCollection with your code's sortBlock reversed I get: > | aCollection | > aCollection := SortedCollection sortBlock: [ :a :b | b <= a ]. > {#k->'Some'. #k->'Value'. #k->'Or'. #k->'Other'} do: [ :each | aCollection > add: each ]. > aCollection. > "a SortedCollection(#k->'Some' #k->'Value' #k->'Or' #k->'Other')" > > The order of the result is the same in both situations. What I would expect > is the result you get from the sortBlock I suggested: > | aCollection | > aCollection := SortedCollection sortBlock: [ :a :b | (a <= b) not ]. > {#k->'Some'. #k->'Value'. #k->'Or'. #k->'Other'} do: [ :each | aCollection > add: each ]. > aCollection. > "a SortedCollection(#k->'Other' #k->'Or' #k->'Value' #k->'Some')" > > This last result is the reversal of the original result. > > (side note) > IF in the above #addAll: was used instead of the repeated #add:, things > might be different again. Since the #addAll: implementation would on some > occasions (when size of receiver vs size of added elements is certain > ratio) > add the elements at the end and then perform a #reSort. With values being > compared as equal, the order will be decided by the order they were added. > So the result of #addAll: depends on the collection sizes. This might not > be > what a user would expect ;-). > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > >

April 24, 2018

UFFI and autoRelease

by Serge Stinckwich

I'm using autoRelease on some FFIOpaqueObject instances. I need to test some behavior when I delete explicitly one of these objects. âHow to remove these objects from the finalization list, in order they are not freed two times. Something like ignoreFinalization ? -- Serge Stinckwich UMI UMMISCO 209 (SU/IRD/UY1) "Programs must be written for people to read, and only incidentally for machines to execute."http://www.doesnotunderstand.org/

April 24, 2018

Re: [Pharo-users] SortedCollection>>reverse answers an inconsistent object in Pharo 6

by Richard O'Keefe

"sortBlock is supposed to act like #<=" means "for every triple of elements x y z that might be in the collection, b(x,x) is true b(x,y) is Boolean b(x,y) | b(y,x) b(x,y) & b(y,z) implies b(x,z)." The first condition distinguishes it from #< . In particular, if you want to sort a sequence of *identical* elements, the sortBlock must satisfy b(x,x). There are other predicates around that act like <= in the relevant sense: >= for example. But #beginsWith: and #endsWith: don't satisfy dichotomy. On 24 April 2018 at 02:43, Erik Stel <erik.stel(a)gmail.com> wrote: > Richard, > > Can you explain me what you mean by "sortBlock is supposed to act like > #<="? > Isn't it up to the developer to decide what the logic should be? I simply > used #<= because #> might not have been implemented for all relevant > classes, but would otherwise have chosen #> as a means to get the > 'reversal' > of #<=. > > Your solution is not resulting in the behaviour I would expect it. Adding > elements which are compared equally, but still have a different value, do > not get added in the same position. In the examples below I use > Associations, since it compares on the key only (for #<= comparison). > > Consider a regular SortedCollection with default sortBlock (set > explicitly): > | aCollection | > aCollection := SortedCollection sortBlock: [ :a :b | a <= b ]. > {#k->'Some'. #k->'Value'. #k->'Or'. #k->'Other'} do: [ :each | aCollection > add: each ]. > aCollection. > "a SortedCollection(#k->'Some' #k->'Value' #k->'Or' #k->'Other')" > > When I create a SortedCollection with your code's sortBlock reversed I get: > | aCollection | > aCollection := SortedCollection sortBlock: [ :a :b | b <= a ]. > {#k->'Some'. #k->'Value'. #k->'Or'. #k->'Other'} do: [ :each | aCollection > add: each ]. > aCollection. > "a SortedCollection(#k->'Some' #k->'Value' #k->'Or' #k->'Other')" > > The order of the result is the same in both situations. What I would expect > is the result you get from the sortBlock I suggested: > | aCollection | > aCollection := SortedCollection sortBlock: [ :a :b | (a <= b) not ]. > {#k->'Some'. #k->'Value'. #k->'Or'. #k->'Other'} do: [ :each | aCollection > add: each ]. > aCollection. > "a SortedCollection(#k->'Other' #k->'Or' #k->'Value' #k->'Some')" > > This last result is the reversal of the original result. > > (side note) > IF in the above #addAll: was used instead of the repeated #add:, things > might be different again. Since the #addAll: implementation would on some > occasions (when size of receiver vs size of added elements is certain > ratio) > add the elements at the end and then perform a #reSort. With values being > compared as equal, the order will be decided by the order they were added. > So the result of #addAll: depends on the collection sizes. This might not > be > what a user would expect ;-). > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > >

April 24, 2018

Re: [Pharo-users] Right repo for TaskIt and features?

by Santiago Bragagnolo

Hi Holger! I respond in *bold* On Tue, 24 Apr 2018 at 12:00 Holger Freyther <holger(a)freyther.de> wrote: > Hey! > > I look into using Taskit for a new development and wondered about some > features. What is the right upstream repository? *The main repo so far is https://github.com/sbragagnolo/taskit <https://github.com/sbragagnolo/taskit>* > What are the goals to get builds greens? *Don't have really a strategy yet, I did not have time to check on them. I can put my hands on it for a while and come up with a plan on that * > I wondered if somebody thought of remote task execution? > ** If by remote calls you mean through REST Api's or things like that, no yet. but is easy to use as: * *[ service call ] schedule. * *or* *result := [ service call ] future * ** If what you mean is to execute a program on the underlying operative system, we have a already a way to do it for linux (not tested on mac, but it may work there) * *result := [ :spec | * * spec* * command: 'bash';* * option: '-c';* * argument: command ] asOSTask future.* *The result deployed on the future is the stdout of the process .* *The text on the exception, the one on stderr of the process. * *Is based on OSSubProcess, it does not work properly with long stdout. * ** If what you mean is the execution of code deployed on other images, earlier versions of taskit had this feature, based on OSProcess, but we are not really ready for doing it for real. We need to be able to define if an image is suitable or not to run a command. * **If you mean something else, I would need more information :).* > What I am missing is handling for overload. E.g. before queuing too many > tasks I would prefer an exception to be raised (or the task > blocking/slowing down). Signalling an exception is probably more reasonable > as one task could queue another task (while >>#value is being executed...). > What are the plans here? I can mitigate by always using futures and using > >>#waitForCompletion:.. > **For raising exceptions on too much tasks you only need to set a custom made kind of queue. I don't think this is the way we want to go. Since there is not much to do in the case of 'too much tasks scheduled'. Is easy to try later from a do-it, but from an application point of view, is too much. * *For dealing with the sharing of resources, we have implemented the worker pools abstractions. * *When you do [ action ] schedule / [ action ] future, both created tasks are scheduled into the default runner. The default runner is a working pool with a default 'poolSizeMax' on 4, meaning, limit 4 processes working over the tasks. (this is a dynamic configuration, you can change it by * *TKTConfiguration runner poolMaxSize: 20. )* > > Are there ideas how to add remote task scheduling? Maybe use Seamless for > it? *Since you speak about seamless here, i suppose two different images, doesn't matter where. * *It's not a bad idea to go seamless, but i did not go through the first restriction of remote executions (if the remote image can or not execute the task and if both images share the same semantic for the execution), then i did not yet checked on which communication platform to use for it * > Have workers connect to the scheduler? Other ideas? *what do you mean by connection to the scheduler? The workers we use do not know their pools, if that is what you mean. * > Who would have time to review an approach and the code? *You can send it to me, Disclaimer, i am going on vacations for a while tomorrow* *Nice to know your interests! * *cheers.* *Santiago* > > cheers > holger >

April 24, 2018

Re: [Pharo-users] Proper way to file in code

by Sven Van Caekenberghe

> On 24 Apr 2018, at 11:52, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > Hi, > > I think the more proper API to use is > > CodeImporter evaluateFileNamed: '/path/to/my/file.st'. > > Check CodeImporter class side for more options (streams, strings...). > > CodeImporter is there for already 3/4 years I think. The idea is that filing in is not a file responsibility. Yeah, but then you should change it to no longer use the deprecated FileStream ;-) See CodeImporter class>>#fileNamed: > Guille > > On Mon, Apr 23, 2018 at 10:35 PM, Hilaire <hilaire(a)drgeo.eu> wrote: > That's a plan! > > I realized from my code I was already using a mix of the new and old world. It will be nice to get rid of the antic one to reduce the confusion when manipulating file. > > Thanks > > Le 22/04/2018 Ã 20:12, Sven Van Caekenberghe a Ã©crit : > It is not hard at all, just start from FileSystem (i.e. FileReference, FileLocator, etc, ..) and open your streams from there and you are good. I guess the FileSystem from the Deep into Pharo book is a good start. > > From a user perspective, the changes are not that big. If something is not clear, you can always ask. > > -- > Dr. Geo > http://drgeo.eu > > > > > > > -- > > 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

April 24, 2018

Right repo for TaskIt and features?

by Holger Freyther

Hey! I look into using Taskit for a new development and wondered about some features. What is the right upstream repository? What are the goals to get builds greens? I wondered if somebody thought of remote task execution? What I am missing is handling for overload. E.g. before queuing too many tasks I would prefer an exception to be raised (or the task blocking/slowing down). Signalling an exception is probably more reasonable as one task could queue another task (while >>#value is being executed...). What are the plans here? I can mitigate by always using futures and using >>#waitForCompletion:.. Are there ideas how to add remote task scheduling? Maybe use Seamless for it? Have workers connect to the scheduler? Other ideas? Who would have time to review an approach and the code? cheers holger

April 24, 2018