March 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Seaside Book: Chapter 17, Serving Files

by Schwab,Wilhelm K

Francois, I am probably missing something too<g>, but dynamically serving the documents is EASY, and that message should get out. The app in question originally ran on a server. At first, that was a way to get around my lack (at the time) of good file synchronizing on Linux - I have long since ported to Pharo a tool that I have use for years so that it runs on Linux. That makes it easy to move files from one machine to another (basically between desktop and laptop). Having the system on a server offered the option for others to see the data, but they never used it. IT policies became problematic (or at least scary), and it is simply easier for to run it locally, so I took that plunge. The system has security features that make little sense now; I might remove them some day. When it ran on a server, I simply generated urls for the full text articles. At present, serving the files dynamically "just works" and does it w/o the need to think about servers and URLs. It is a nice solution that I think deserves mention along with FileLibrary and other methods. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Francois Stephany [tulipe.moutarde(a)gmail.com] Sent: Sunday, March 25, 2012 11:23 PM To: pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Seaside Book: Chapter 17, Serving Files Hi Bill, I probably miss something in the use case but why don't you simply serve that static content with Kom or Zinc ? On 25/03/12 18:29, Schwab,Wilhelm K wrote: > Clearly, I can't put hundreds of megabytes in a FileLibrary, and I have > no interest in configuring a static web server for something that (sadly > or not) runs locally on multiple machines, with data synchronized via > what amounts to an rsynch clone and ever-growing flash sticks.

March 26, 2012

Re: [Pharo-project] Seaside Book: Chapter 17, Serving Files

by Francois Stephany

Hi Bill, I probably miss something in the use case but why don't you simply serve that static content with Kom or Zinc ? On 25/03/12 18:29, Schwab,Wilhelm K wrote: > Clearly, I can't put hundreds of megabytes in a FileLibrary, and I have > no interest in configuring a static web server for something that (sadly > or not) runs locally on multiple machines, with data synchronized via > what amounts to an rsynch clone and ever-growing flash sticks.

March 26, 2012

[Pharo-project] Cog-Win32 build on Jenkins

by Martin Sandiford

Hi All, Any chance that the "Cog-Win32" Jenkins job could be made dependent on the "Cog Git Tracker (blessed)" job in the same way as the Mac and Linux VMs are? I ask because I see that the job hasn't been built after the last couple of changes to the blessed repo. Cheers, Martin

March 26, 2012

[Pharo-project] Seaside Book: Chapter 17, Serving Files

by Schwab,Wilhelm K

Stef, Thanks for Dynamic Web Development With Seaside - it's a great book! One omission that I have noted is that of dynamically serving files. Making a long story short, I have a Seaside app that swallows and regurgitates literature (300 MB and growing). It is what has me interested in Citezen (which is working wonderfully - thanks again!). I wish I had known more about Seaside when I started to write it, but it is slowly improving. Clearly, I can't put hundreds of megabytes in a FileLibrary, and I have no interest in configuring a static web server for something that (sadly or not) runs locally on multiple machines, with data synchronized via what amounts to an rsynch clone and ever-growing flash sticks. The answer is to serve the content dynamically, as below. I think this technique deserves mention in Chapter 17. Bill serveFileNamed:fileName for:component canvas:html | mimeType | ( File splitExtensionFrom:fileName ) = 'pdf' ifTrue:[ mimeType := 'application/pdf' ]. ( File splitExtensionFrom:fileName ) = 'txt' ifTrue:[ mimeType := 'application/text' ]. ( File splitExtensionFrom:fileName ) = 'gz' ifTrue:[ mimeType := 'application/x-gzip' ]. component session requestContext respond:[ :response | response document:self fullTextAsString mimeType:mimeType fileName:fileName; doNotCache ]

March 26, 2012

Re: [Pharo-project] vm crash - code snippet provided

by Francisco Garau

It's used to "animate" the morphs, apparently. The crash happens quite easily by dragging a big window out of the screen (to the left). You either get a debugger or the vm crashes. I just want to point out that before the VM crashes, there is a bug in Smalltalk-land; an Number is appearing where a Point is expected. - Francisco On 26 March 2012 00:13, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 26 March 2012 00:16, Francisco Garau <francisco.garau(a)gmail.com> wrote: > > Hi - a short code snippet that crashes the CogVM in WindowsXP using a > fresh > > Pharo 1.4 image. > > > > Open a System Browser and evaluate the below in a Workspace. > > > > window := SystemWindow allInstances first. > > aForm := window imageForm offset: 0@0. > > startPoint := (-194@61). > > endPoint := (276.0(a)134.0) > > aForm > > slideFrom: startPoint > > to: endPoint > > nSteps: 12 > > delay: 15. > > > > thanks for report. i never seen/used this method.. > > > Cheers, > > Francisco > > > > -- > Best regards, > Igor Stasenko. > >

March 25, 2012

Re: [Pharo-project] vm crash - code snippet provided

by Igor Stasenko

On 26 March 2012 00:16, Francisco Garau <francisco.garau(a)gmail.com> wrote: > Hi - a short code snippet that crashes the CogVM in WindowsXP using a fresh > Pharo 1.4 image. > > Open a System Browser and evaluate the below in a Workspace. > > window := SystemWindow allInstances first. > aForm := window imageForm offset: 0@0. > startPoint := (-194@61). > endPoint := (276.0(a)134.0) > aForm > Â Â Â Â Â Â Â slideFrom: startPoint > Â Â Â Â Â Â Â to: endPoint > Â Â Â Â Â Â Â nSteps: 12 > Â Â Â Â Â Â Â delay: 15. > thanks for report. i never seen/used this method.. > Cheers, > Francisco -- Best regards, Igor Stasenko.

March 25, 2012

Re: [Pharo-project] Announcement vs SystemChangeNotifier

by Igor Stasenko

On 25 March 2012 21:49, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi guys > > I'm starting to look at how we can remove SystemChangeNotifier to only use SystemAnnouncement. > Now > Â Â Â Â Is there an equivalent to > Â Â Â Â Â Â Â Â SystemChangeNotifier uniqueInstance doSilently: [â¦â¦] > > Â Â Â Â for Announcement? > well, you can implement disabling announcer for a while.. announcer disableWhile: [... ... any announces here wont be delivered ..]. easy > Stef -- Best regards, Igor Stasenko.

March 25, 2012

[Pharo-project] File browser with a grid widget

by Alexis Parseghian

I've always found the file browser's flat list over filenames a bit missing, and started experimenting with a grid view. The current version offers 3 columns : filename, size and modification timestamp. Sorting can be on any of them (filename by default). http://code.google.com/p/pharo/issues/detail?id=5549

March 25, 2012

[Pharo-project] vm crash - code snippet provided

by Francisco Garau

Hi - a short code snippet that crashes the CogVM in WindowsXP using a fresh Pharo 1.4 image. Open a System Browser and evaluate the below in a Workspace. window := SystemWindow allInstances first. aForm := window imageForm offset: 0@0. startPoint := (-194@61). endPoint := (276.0(a)134.0) aForm slideFrom: startPoint to: endPoint nSteps: 12 delay: 15. Cheers, Francisco

March 25, 2012

[Pharo-project] CogVM speed

by Pavel Krivanek

Hi, I tried a few benchmarks from Computer Language Benchmark Game (http://shootout.alioth.debian.org/u32/which-programming-languages-are-faste…) on CogVM to compare it with VisualWorks and with the rest of the world. Of course this benchmarks are not ideal (like all benchmarks) but the result is that CogVM is in average 1.8 times slower than VisualWorks 7.8 NC. For the most successful benchmark (binary-trees) it was 13.5 times slower than C (gcc) but in general we may except CogVM to be 20-30 times slower than C for this kind of tasks. Thank you for the great work! Cheers, -- Pavel

March 25, 2012