Re: [Pharo-users] Gitfiletree unstable on Windows
Sorry for replying after so much time... What inteface is it? Is there any way I could help to find source of the problem? Jan Thierry Goubier wrote > Hi Jan, > > there is a chance the problem is in the interface GitFileTree uses to > call git on windows. > > Thierry > > Le 31/03/2015 17:53, Jan B. a écrit : >> This way it loads, but unfortunately VM crashes anyway. >> >> >> Jigyasa Grover wrote >>> Hey Jan >>> >>> Try this: >>> " Metacello new >>>baseline: 'FileTree'; >>>repository: >>> 'filetree:///C:/Users/User/Pharo/../dalehenrich-filetree-7f998e5/repository'; >>>load: 'Git' >>> " >>> >>> Put in the path to the repository folder. >> >> >> >> >> >> -- >> View this message in context: >> http://forum.world.st/Gitfiletree-unstable-on-Windows-tp4816354p4816405.html >> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >> >> >> -- View this message in context: http://forum.world.st/Gitfiletree-unstable-on-Windows-tp4816354p4819490.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Re: [Pharo-users] Gitfiletree unstable on Windows
Hi Jan, It's ProcessWrapper. It uses a dll called ProcessWrapperPlugin.dll (downloaded when you install ProcessWrapper). I'm not sure where is the source code. Thierry 2015-04-14 12:25 GMT+02:00 Jan Blizničenko : > Sorry for replying after so much time... > > What inteface is it? Is there any way I could help to find source of the > problem? > > Jan > > > Thierry Goubier wrote > > Hi Jan, > > > > there is a chance the problem is in the interface GitFileTree uses to > > call git on windows. > > > > Thierry > > > > Le 31/03/2015 17:53, Jan B. a écrit : > >> This way it loads, but unfortunately VM crashes anyway. > >> > >> > >> Jigyasa Grover wrote > >>> Hey Jan > >>> > >>> Try this: > >>> " Metacello new > >>>baseline: 'FileTree'; > >>>repository: > >>> > 'filetree:///C:/Users/User/Pharo/../dalehenrich-filetree-7f998e5/repository'; > >>>load: 'Git' > >>> " > >>> > >>> Put in the path to the repository folder. > >> > >> > >> > >> > >> > >> -- > >> View this message in context: > >> > http://forum.world.st/Gitfiletree-unstable-on-Windows-tp4816354p4816405.html > >> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >> > >> > >> > > > > > > -- > View this message in context: > http://forum.world.st/Gitfiletree-unstable-on-Windows-tp4816354p4819490.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >
[Pharo-users] DoubleLinkedList vs LinkedList vs Collection
I was surprised to learn that DoubleLinkedList is descendant of Object, while LinkedList is descendant of SequencableCollection. Is there a particular reason behind this? Are they really so conceptually different that DLL is not even considered a collection? Thanks, Peter
Re: [Pharo-users] DoubleLinkedList vs LinkedList vs Collection
Peter, > On 14 Apr 2015, at 13:52, Peter Uhnák wrote: > > I was surprised to learn that DoubleLinkedList is descendant of Object, while > LinkedList is descendant of SequencableCollection. Is there a particular > reason behind this? Are they really so conceptually different that DLL is not > even considered a collection? > > Thanks, > Peter DoubleLinkedList was added to help the implementation of [LRU|TTL]Cache. It was kept small and independent. Inheriting from [Sequenceable]Collection is a larger responsibility, entails more requirements. I would not be against this, although I am not 100% sure it is easy (some methods return the link nodes, not the elements, a distinction unknown to collections in general - LinkedList is a bit ugly in this respect too). In any case, it would have to be supported by enough tests. It could be a nice project for Pharo 5. Sven
Re: [Pharo-users] DoubleLinkedList vs LinkedList vs Collection
> On 14 Apr 2015, at 14:00, Sven Van Caekenberghe wrote: > > Peter, > >> On 14 Apr 2015, at 13:52, Peter Uhnák wrote: >> >> I was surprised to learn that DoubleLinkedList is descendant of Object, >> while LinkedList is descendant of SequencableCollection. Is there a >> particular reason behind this? Are they really so conceptually different >> that DLL is not even considered a collection? >> >> Thanks, >> Peter > > DoubleLinkedList was added to help the implementation of [LRU|TTL]Cache. It > was kept small and independent. > > Inheriting from [Sequenceable]Collection is a larger responsibility, entails > more requirements. > > I would not be against this, although I am not 100% sure it is easy (some > methods return the link nodes, not the elements, a distinction unknown to > collections in general - LinkedList is a bit ugly in this respect too). In > any case, it would have to be supported by enough tests. It could be a nice > project for Pharo 5. One problem with LinkedList is that it is used by the scheduler and carefully written to be intererrupt-check free in some (undocumented) cases… in the past this has already lead to very bad side-effects when people wanted to improve it or change it. Marcus
Re: [Pharo-users] DoubleLinkedList vs LinkedList vs Collection
Peter Uhnák wrote > Are they really so conceptually different > that DLL is not even considered a collection? I just reread GOF and reinforced an important idea. Although we often conflate the two, types and classes are not the same. Inheritance is an implementation detail about avoiding duplication by sharing code. Unfortunately, Smalltalk may encourage the conflation because: 1. interfaces are not well-defined 2. and, the tools, being very class-centric, and maybe in reaction to #1, make it tempting to subclass just to make the relationships clearer whether there is code savings or not So the question is whether they are implementation-ally similar enough to justify subclassing. Their conceptual similarity only means they should share the same interface i.e. respond to the same set of messages. - Cheers, Sean -- View this message in context: http://forum.world.st/DoubleLinkedList-vs-LinkedList-vs-Collection-tp4819508p4819516.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Re: [Pharo-users] DoubleLinkedList vs LinkedList vs Collection
> > DoubleLinkedList was added to help the implementation of [LRU|TTL]Cache. > It was kept small and independent. Does that mean that I probably shouldn't touch it? Because when I wanted to use DDL I ran into a problem that once I add something to the list, I can no longer access the Links. LinkedList has "firstLink/lastLink", but this is missing in DoubleLinkedList -- is this design decision (to keep it small), or nobody needed it until now? Peter
Re: [Pharo-users] DoubleLinkedList vs LinkedList vs Collection
Also linksDo: method is missing. On Tue, Apr 14, 2015 at 4:46 PM, Peter Uhnák wrote: > DoubleLinkedList was added to help the implementation of [LRU|TTL]Cache. >> It was kept small and independent. > > Does that mean that I probably shouldn't touch it? Because when I wanted > to use DDL I ran into a problem that once I add something to the list, I > can no longer access the Links. LinkedList has "firstLink/lastLink", but > this is missing in DoubleLinkedList -- is this design decision (to keep it > small), or nobody needed it until now? > > Peter >
Re: [Pharo-users] DoubleLinkedList vs LinkedList vs Collection
> On 14 Apr 2015, at 16:46, Peter Uhnák wrote: > > DoubleLinkedList was added to help the implementation of [LRU|TTL]Cache. It > was kept small and independent. > Does that mean that I probably shouldn't touch it? Because when I wanted to > use DDL I ran into a problem that once I add something to the list, I can no > longer access the Links. LinkedList has "firstLink/lastLink", but this is > missing in DoubleLinkedList -- is this design decision (to keep it small), or > nobody needed it until now? Both ;-) > Peter Please make an issue with the API that you think should be added, and then we can have a look for Pharo 5. Sven
Re: [Pharo-users] DoubleLinkedList vs LinkedList vs Collection
I guess the "System-Caching" package which I noticed just now is a bit telling. :) I'll make an issue. Peter On Tue, Apr 14, 2015 at 5:02 PM, Sven Van Caekenberghe wrote: > > > On 14 Apr 2015, at 16:46, Peter Uhnák wrote: > > > > DoubleLinkedList was added to help the implementation of [LRU|TTL]Cache. > It was kept small and independent. > > Does that mean that I probably shouldn't touch it? Because when I wanted > to use DDL I ran into a problem that once I add something to the list, I > can no longer access the Links. LinkedList has "firstLink/lastLink", but > this is missing in DoubleLinkedList -- is this design decision (to keep it > small), or nobody needed it until now? > > Both ;-) > > > Peter > > Please make an issue with the API that you think should be added, and then > we can have a look for Pharo 5. > > Sven > > >
Re: [Pharo-users] DoubleLinkedList vs LinkedList vs Collection
> On 14 Apr 2015, at 2:09 , Marcus Denker wrote: > > >> On 14 Apr 2015, at 14:00, Sven Van Caekenberghe wrote: >> >> Peter, >> >>> On 14 Apr 2015, at 13:52, Peter Uhnák wrote: >>> >>> I was surprised to learn that DoubleLinkedList is descendant of Object, >>> while LinkedList is descendant of SequencableCollection. Is there a >>> particular reason behind this? Are they really so conceptually different >>> that DLL is not even considered a collection? >>> >>> Thanks, >>> Peter >> >> DoubleLinkedList was added to help the implementation of [LRU|TTL]Cache. It >> was kept small and independent. >> >> Inheriting from [Sequenceable]Collection is a larger responsibility, entails >> more requirements. >> >> I would not be against this, although I am not 100% sure it is easy (some >> methods return the link nodes, not the elements, a distinction unknown to >> collections in general - LinkedList is a bit ugly in this respect too). In >> any case, it would have to be supported by enough tests. It could be a nice >> project for Pharo 5. > > One problem with LinkedList is that it is used by the scheduler and carefully > written to be intererrupt-check free in some (undocumented) cases… in the past > this has already lead to very bad side-effects when people wanted to improve > it or change it. > > Marcus IIRC, #removeLink:ifAbsent: is the only method (... that we've noticed) that needs to be atomic for the scheduler to work.(in other words, it can end up trying to remove the same process from different threads at the same time) The change was made during a sprint to allow adding arbitrary objects and create links on the fly (inspired by Ruby, or so I was told), in the process the old remove:ifAbsent: turned into removeLink:ifAbsent, and a suspension point was introduced in the process, which meant, once in a blue moon, the scheduler would get stuck trying to remove a process that had already been removed. In other words; it's not a pleasant class to change. WRT being a subclass of SequenceableCollection; while technically true, that API is much wider than what you'd expect from a classic link list, and the inherited implementations mostly assume O(1) #at: performance. Very little is reimplemented, so most of it is rather slow if you try to actually use any of it: ll := LinkedList withAll:#(a b c d e f g h i j k l m n o p q r s t u v x y z). [ll allButFirst: 15] bench '150,365 per second' aa := Array withAll: #(a b c d e f g h i j k l m n o p q r s t u v x y z). [aa allButFirst: 15] bench 10,055,029 per second Aside from pure bugs, there's also other oddities like the species being Array, but iteration methods reimplemented using self class. IOW: If you are looking for a LinkedList actually worth using, look elsewhere. DoubleLinkedList may not be a Collection, but at least the API is small enough to grasp, and the parts that are there act as you expect them to. Cheers, Henry
Re: [Pharo-users] [ANN] ArchLinux pharo-vm / pharo-launcher packages
Hi Markus, I've updated the package and now it should work. Note that the pkg files are hosted at https://github.com/lolgzs/pharo-aur/ Cheers, Laurent Le lun. 13 avril 2015 à 22:56, Markus Schlager a écrit : Hi Laurent, On Tue, 18 Mar 2014, Laurent Laffont wrote: There's also a pharo-launcher package that depends on pharo-vm: $ yaourt pharo-launcher Right know this fails raising a 404 File Not Found error: --2015-04-13 22:51:47-- https://ci.inria.fr/pharo-contribution/job/PharoLauncherFinalUserImage/lastSuccessfulBuild/artifact/PharoLauncher.zip Auflösen des Hostnamens »ci.inria.fr (ci.inria.fr)« … 193.51.193.223 Verbindungsaufbau zu ci.inria.fr (ci.inria.fr)|193.51.193.223|:443 … verbunden. HTTP-Anforderung gesendet, auf Antwort wird gewartet … 404 Not Found 2015-04-13 22:51:47 FEHLER 404: Not Found. Markus
Re: [Pharo-users] [ANN] ArchLinux pharo-vm / pharo-launcher packages
This downloads the latest vm (not image) at http://files.pharo.org/vm/pharo/linux/latest.zip Laurent Le lun. 13 avril 2015 à 20:03, Sean P. DeNigris a écrit : laurent laffont wrote $ yaourt pharo-vm-latest Does this download the stable or development version of Pharo? - Cheers, Sean -- View this message in context: http://forum.world.st/ANN-ArchLinux-pharo-vm-pharo-launcher-packages-tp4749668p4819393.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Re: [Pharo-users] [ANN] ArchLinux pharo-vm / pharo-launcher packages
Hi Laurent, On Tue, 14 Apr 2015, Laurent wrote: I've updated the package and now it should work. It does :) Thanks a lot Markus
Re: [Pharo-users] DoubleLinkedList vs LinkedList vs Collection
I think that LinkedList should be a private class nobody should use :). Better use DoubleLinkedList which should be packaged with extended collection. Le 14/4/15 17:07, Henrik Johansen a écrit : On 14 Apr 2015, at 2:09 , Marcus Denker wrote: On 14 Apr 2015, at 14:00, Sven Van Caekenberghe wrote: Peter, On 14 Apr 2015, at 13:52, Peter Uhnák wrote: I was surprised to learn that DoubleLinkedList is descendant of Object, while LinkedList is descendant of SequencableCollection. Is there a particular reason behind this? Are they really so conceptually different that DLL is not even considered a collection? Thanks, Peter DoubleLinkedList was added to help the implementation of [LRU|TTL]Cache. It was kept small and independent. Inheriting from [Sequenceable]Collection is a larger responsibility, entails more requirements. I would not be against this, although I am not 100% sure it is easy (some methods return the link nodes, not the elements, a distinction unknown to collections in general - LinkedList is a bit ugly in this respect too). In any case, it would have to be supported by enough tests. It could be a nice project for Pharo 5. One problem with LinkedList is that it is used by the scheduler and carefully written to be intererrupt-check free in some (undocumented) cases… in the past this has already lead to very bad side-effects when people wanted to improve it or change it. Marcus IIRC, #removeLink:ifAbsent: is the only method (... that we've noticed) that needs to be atomic for the scheduler to work.(in other words, it can end up trying to remove the same process from different threads at the same time) The change was made during a sprint to allow adding arbitrary objects and create links on the fly (inspired by Ruby, or so I was told), in the process the old remove:ifAbsent: turned into removeLink:ifAbsent, and a suspension point was introduced in the process, which meant, once in a blue moon, the scheduler would get stuck trying to remove a process that had already been removed. In other words; it's not a pleasant class to change. WRT being a subclass of SequenceableCollection; while technically true, that API is much wider than what you'd expect from a classic link list, and the inherited implementations mostly assume O(1) #at: performance. Very little is reimplemented, so most of it is rather slow if you try to actually use any of it: ll := LinkedList withAll:#(a b c d e f g h i j k l m n o p q r s t u v x y z). [ll allButFirst: 15] bench '150,365 per second' aa := Array withAll: #(a b c d e f g h i j k l m n o p q r s t u v x y z). [aa allButFirst: 15] bench 10,055,029 per second Aside from pure bugs, there's also other oddities like the species being Array, but iteration methods reimplemented using self class. IOW: If you are looking for a LinkedList actually worth using, look elsewhere. DoubleLinkedList may not be a Collection, but at least the API is small enough to grasp, and the parts that are there act as you expect them to. Cheers, Henry
Re: [Pharo-users] DoubleLinkedList vs LinkedList vs Collection
+1 Stef Le 14/4/15 17:02, Sven Van Caekenberghe a écrit : On 14 Apr 2015, at 16:46, Peter Uhnák wrote: DoubleLinkedList was added to help the implementation of [LRU|TTL]Cache. It was kept small and independent. Does that mean that I probably shouldn't touch it? Because when I wanted to use DDL I ran into a problem that once I add something to the list, I can no longer access the Links. LinkedList has "firstLink/lastLink", but this is missing in DoubleLinkedList -- is this design decision (to keep it small), or nobody needed it until now? Both ;-) Peter Please make an issue with the API that you think should be added, and then we can have a look for Pharo 5. Sven
Re: [Pharo-users] Zinc, servicing a full website
Hi Leo,
> On 14 Apr 2015, at 14:28, Leo Paniceres wrote:
>
> Hi Sven,
>
> Thanks very much for your excellent Zinc package.
>
> Excuse me for contacting to your email, I couldn’t find the official support
> email list.
I much prefer answering question on the pharo-users ML, in CC.
> My problem is that I could not find a way to solve simultaneously file
> servicing and services.
>
> I have a small app that responds to a request via a GET, and I also need to
> include in the response a lot of static files in a directory.
>
> How can I integrate two delegates?
>
> (ZnStaticFileServerDelegate and ZnDefaultServerDelegate)
This is from an older answer, it should be applicable:
Multiple handlers can be combined in one server. For example, http://zn.stfx.eu
serves static content and serves all Zinc demos, with the following config
(part of the startup script):
| id logFile staticFileServerDelegate |
id := 1.
logFile := 'transcript.{1}.log' format: { id }.
(NonInteractiveTranscript onFileNamed: logFile) install.
(ZnServer defaultOn: 8080 + id)
logToTranscript;
route: 'r', id printString;
start.
(staticFileServerDelegate := ZnStaticFileServerDelegate new)
prefixFromString: 'zn';
directory: '/home/ubuntu/zn' asFileReference.
ZnServer default delegate prefixMap
at: 'zn'
put: [ :request | staticFileServerDelegate handleRequest: request ];
at: 'redirect-to-zn'
put: [ :request | ZnResponse redirect: '/zn/index.html' ];
at: '/'
put: 'redirect-to-zn'.
HTH,
Sven
> --
>
> Afectuosamente desde Argentina, (de corazón por mas que lo tenga automatico)
> Leo
