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

[Pharo-project] Seaside request contexts and the Pharo debugger - solved wth a slight mystery

by Schwab,Wilhelm K

Paul, all, Thanks for the suggestion, but all appears to be well in Seaside (coming back to it after a while, I'm all the more impressed - it's a wonderful framework!). Below is what I posted on the Pharo list. It *has* to be some kind of Heisenbug in the Pharo debugger, or a bad interaction between same and Seaside. When I first set out to load the files and create mime types to serve them dynamically (it's more than fast enough for what I need, takes no new configuration on target machines, does not bloat a file library (200MB of stuff!!!, but served in smallish pieces, hence dynamic mime is great for it). End of sales pitch :) The important thing is that it works!!! Making a long story short, when I first went to create the mime document, I set a breakpoint at the top of a method called from my callback. It has access to canvas and component, but inspecting component requestContext would give a not-found error. Let the code run past that, and all is well =:0 My code looks something like this: serveFileNamed:fileName for:component canvas:html component session requestContext respond:[ :response | response document:self fullTextAsString mimeType:'application/pdf' fileName:fileName; doNotCache ] which is called inside a callback for a "full text" anchor. I can freely debug inside of #fullTextAsString, which was what I really needed to do because the paths were tricky to get right. Success. Thanks again! Bill ================= Got it!! I am now serving pdfs from my local drive w/o a file library and w/o an external web server. All goes through finding the file, loading the bytes and wrapping it a mime document. Like I said, security paranoia or laziness - pick one, but it's what I wanted. There is *something* preventing me from being able to set a breakpoint and evaluating code that should result in a working request context. Setting breakpoints *after* the context is found does work. I was able to use the debugger to good effect in getting the mime document and file naming sorted out. -------------------------------- Paul DeBruicker pdebruic at gmail.com <mailto:seaside%40lists.squeakfoundation.org?Subject=%5BSeaside%5D%20WAReque…> Fri Mar 16 16:26:22 UTC 2012 * Previous message: [Seaside] WARequestContextNotFound - where to look for a context? <http://lists.squeakfoundation.org/pipermail/seaside/2012-March/028462.html> * Next message: [Seaside] Local Anchor <http://lists.squeakfoundation.org/pipermail/seaside/2012-March/028471.html> * Messages sorted by: [ date ]<http://lists.squeakfoundation.org/pipermail/seaside/2012-March/date.html#28…> [ thread ]<http://lists.squeakfoundation.org/pipermail/seaside/2012-March/thread.html#…> [ subject ]<http://lists.squeakfoundation.org/pipermail/seaside/2012-March/subject.html…> [ author ]<http://lists.squeakfoundation.org/pipermail/seaside/2012-March/author.html#…> ________________________________ On 12-03-15 10:34 AM, Schwab,Wilhelm K wrote: > . The archive in question is way too big for a FileLibrary and a > separate web server is probably overkill since I intend to do all of > this locally and would rather not have to run Apache on the machines in > question (security paranoia or laziness, You can serve static files from disk with Comanche if you want. See: http://samadhiweb.com/blog/2011.07.10.seaside.comanche.staticfiles.html for configuration ideas.

March 17, 2012

[Pharo-project] Pharo Kernel Reload Tests-Unix - Build # 13 - Still Unstable!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

March 16, 2012

[Pharo-project] Pharo 1.4 Tests-Unix - Build # 290 - Still Unstable!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

March 16, 2012

[Pharo-project] [update 1.4] #14397

by StÃ©phane Ducasse

14397 ----- - Issue 5488: New pass on RecentMessageList. http://code.google.com/p/pharo/issues/detail?id=5488 Thanks Benjamin van Ryseghem

March 16, 2012

[Pharo-project] Bug fix for InputEventSensor (incomplete initialization)

by Alexandre Bergel

Ready to be reviewed: http://code.google.com/p/pharo/issues/detail?id=5501 Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

March 16, 2012

Re: [Pharo-project] Seaside image

by Schwab,Wilhelm K

Got it!! I am now serving pdfs from my local drive w/o a file library and w/o an external web server. All goes through finding the file, loading the bytes and wrapping it a mime document. Like I said, security paranoia or laziness - pick one, but it's what I wanted. There is *something* preventing me from being able to set a breakpoint and evaluating code that should result in a working request context. Setting breakpoints *after* the context is found does work. I was able to use the debugger to good effect in getting the mime document and file naming sorted out. Bill ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Schwab,Wilhelm K [bschwab(a)anest.ufl.edu] Sent: Friday, March 16, 2012 11:37 AM To: pharo-project(a)lists.gforge.inria.fr Subject: [Pharo-project] Seaside image Hello all, I have started to resurrect some of my Seaside code (originally written for 2.8) in the Seaside downstream image for Pharo 1.3 (Seaside 3, I think??). I can't do anything with request contexts in the image. I can try loading Seaside myself in a new image, but I was wondering if anyone has seen this. Bill ----------------- I don't understand what you have been doing wrong. "WACurrenrRequestContext value" will always be available if you are inside a callback or rendering - virtually anywhere in Seaside. Wherever you have a WAComponent you can also send #session to it. On 15 March 2012 18:34, Schwab,Wilhelm K <bschwab at anest.ufl.edu<http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside>> wrote: > I am trying to create anchors that will "dynamically" serve pdf > documents. The archive in question is way too big for a FileLibrary and a > separate web server is probably overkill since I intend to do all of this > locally and would rather not have to run Apache on the machines in question > (security paranoia or laziness, take your pick<g>) . So, I was hoping to > create mime documents on the fly. > > I found suggestions such as: > > component session requestContext respond:[ :response | > response > document:self getPdfBytes > mimeType: 'application/pdf' > fileName: 'seaside-test.pdf'; > doNotCache > > I don't see #getPdfBytes, but suspect I can wing it given the file names > in anchors. > > The problem is that everything I ask for a requestContext feigns > ignorance. I can't even get #session because of the same error. I am > using Seaside 3 from the Pharo 1.3 image and Seaside downstream project. > > Any suggestions? > > Bill

March 16, 2012

Re: [Pharo-project] Seaside image

by Schwab,Wilhelm K

Hello all, This appears to be some type of Heisenbug. If I set a breakpoint in a callback, I can't do anything with request contexts - "not found" errors happen every time I try to evaluate code that should lead to one. BUT, if I let the code run past something like component requestContext or component session, all is well. I think I see how to proceed, which is to do my debugging "downstream" of the context access. Any ideas why that is necessary? Oddities include that the entire app runs out of a task. Bill ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Schwab,Wilhelm K [bschwab(a)anest.ufl.edu] Sent: Friday, March 16, 2012 11:37 AM To: pharo-project(a)lists.gforge.inria.fr Subject: [Pharo-project] Seaside image Hello all, I have started to resurrect some of my Seaside code (originally written for 2.8) in the Seaside downstream image for Pharo 1.3 (Seaside 3, I think??). I can't do anything with request contexts in the image. I can try loading Seaside myself in a new image, but I was wondering if anyone has seen this. Bill ----------------- I don't understand what you have been doing wrong. "WACurrenrRequestContext value" will always be available if you are inside a callback or rendering - virtually anywhere in Seaside. Wherever you have a WAComponent you can also send #session to it. On 15 March 2012 18:34, Schwab,Wilhelm K <bschwab at anest.ufl.edu<http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside>> wrote: > I am trying to create anchors that will "dynamically" serve pdf > documents. The archive in question is way too big for a FileLibrary and a > separate web server is probably overkill since I intend to do all of this > locally and would rather not have to run Apache on the machines in question > (security paranoia or laziness, take your pick<g>) . So, I was hoping to > create mime documents on the fly. > > I found suggestions such as: > > component session requestContext respond:[ :response | > response > document:self getPdfBytes > mimeType: 'application/pdf' > fileName: 'seaside-test.pdf'; > doNotCache > > I don't see #getPdfBytes, but suspect I can wing it given the file names > in anchors. > > The problem is that everything I ask for a requestContext feigns > ignorance. I can't even get #session because of the same error. I am > using Seaside 3 from the Pharo 1.3 image and Seaside downstream project. > > Any suggestions? > > Bill

March 16, 2012

Re: [Pharo-project] Seaside image

by Schwab,Wilhelm K

Update: I looked for tests using a request context and found WAInteractionTest; all test pass, and I was able to set a breakpoint and inspect a nice working request context. So the it's not the downstream seaside image that is at fault. Confused... I will admit to some creative use of rendering, but it's all done with "components" that have a #basicRenderContentOn:for: where the second argument is the component doing the rendering. The pieces are abstractions of bibtex (hence my interest in Citezen) entries that I didn't want to fully componentize because they can get very numerous with use. But I render (I *think*) by the rules and am asking what should be a valid canvas or component for the context. I'll keep looking. Bill ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Schwab,Wilhelm K [bschwab(a)anest.ufl.edu] Sent: Friday, March 16, 2012 11:37 AM To: pharo-project(a)lists.gforge.inria.fr Subject: [Pharo-project] Seaside image Hello all, I have started to resurrect some of my Seaside code (originally written for 2.8) in the Seaside downstream image for Pharo 1.3 (Seaside 3, I think??). I can't do anything with request contexts in the image. I can try loading Seaside myself in a new image, but I was wondering if anyone has seen this. Bill ----------------- I don't understand what you have been doing wrong. "WACurrenrRequestContext value" will always be available if you are inside a callback or rendering - virtually anywhere in Seaside. Wherever you have a WAComponent you can also send #session to it. On 15 March 2012 18:34, Schwab,Wilhelm K <bschwab at anest.ufl.edu<http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside>> wrote: > I am trying to create anchors that will "dynamically" serve pdf > documents. The archive in question is way too big for a FileLibrary and a > separate web server is probably overkill since I intend to do all of this > locally and would rather not have to run Apache on the machines in question > (security paranoia or laziness, take your pick<g>) . So, I was hoping to > create mime documents on the fly. > > I found suggestions such as: > > component session requestContext respond:[ :response | > response > document:self getPdfBytes > mimeType: 'application/pdf' > fileName: 'seaside-test.pdf'; > doNotCache > > I don't see #getPdfBytes, but suspect I can wing it given the file names > in anchors. > > The problem is that everything I ask for a requestContext feigns > ignorance. I can't even get #session because of the same error. I am > using Seaside 3 from the Pharo 1.3 image and Seaside downstream project. > > Any suggestions? > > Bill

March 16, 2012

Re: [Pharo-project] Fwd: [Moose-dev] Moose Windows VM problem

by Usman Bhatti

On Thu, Mar 15, 2012 at 11:41 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 14 March 2012 08:00, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > wrote: > > Hi guys > > > > can we fix the one click on windows especially? > > > > Stef > > > > Begin forwarded message: > > > > From: Usman Bhatti <usman.bhatti(a)gmail.com> > > Subject: [Moose-dev] Moose Windows VM problem > > Date: March 13, 2012 6:23:44 PM GMT+01:00 > > To: Moose-related development <moose-dev(a)iam.unibe.ch> > > Reply-To: Moose-related development <moose-dev(a)iam.unibe.ch> > > > > Hello, > > > > I have a one-click moose image downloaded around first week of Feb 2012. > The > > problem with the image is that it's windows vm that does not launch the > > image file. In fact, when I execute the vm, it creates a process > (visible in > > windows task manager) but nothing happens. We tried to debug it with Igor > > but we couldn't (as there is no entry point). The image in the bundle > can be > > launched with latest windows vm (from pharo server) [meaning that the > > problem comes from the vm which we cannot debug]. > > > > I downloaded another moose image today and executed its windows vm, and > its > > working fine. > > > > It would be good to have a jenkins process to run moose on windows vm. > Do we > > have such a setup? If not, I can create one in the coming weeks. > > > I can help with setting it up. More tests never hurt. > Yes. Igor with your help I'll be able to do it fast. I'm off for two weeks, we can do it once I'm back in office. tx usman > > > thanx, > > usman > > _______________________________________________ > > Moose-dev mailing list > > Moose-dev(a)iam.unibe.ch > > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > > > > > > -- > Best regards, > Igor Stasenko. > >

March 16, 2012

[Pharo-project] [update 1.4] #14395

by Marcus Denker

14395 ----- Issue 5494: More fixes to CommandLineUIManager http://code.google.com/p/pharo/issues/detail?id=5494 Issue 5485: Break dependency in SmalltalkImage>>snapshot:andQuit: http://code.google.com/p/pharo/issues/detail?id=5485 -- Marcus Denker -- http://marcusdenker.de

March 16, 2012