March 2013 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Nautilus class references?

by Bernat Romagosa

Ok, I see! Thanks Esteban! Is there a place where one can find a comprehensive list of all the shortcuts? I'm going a bit insane... T_T 2013/3/13 Esteban Lorenzano <estebanlm(a)gmail.com> > with the new commands: cmd+b+N > you also can choose the old keybiindings (in settings), but you will lose > all the power of the new ones :) > > Esteban > > > On Mar 13, 2013, at 11:36 AM, Bernat Romagosa < > tibabenfortlapalanca(a)gmail.com> wrote: > > > Hi list, > > > > How does one get the references to a class in Nautilus? In RB it used to > be control+N, now I can't find it anywhere, not even in the context menus... > > > > Thanks! > > > > Bernat. > > > > -- > > Bernat Romagosa. > > > -- Bernat Romagosa.

March 13, 2013

Re: [Pharo-users] Nautilus class references?

by Esteban Lorenzano

with the new commands: cmd+b+N you also can choose the old keybiindings (in settings), but you will lose all the power of the new ones :) Esteban On Mar 13, 2013, at 11:36 AM, Bernat Romagosa <tibabenfortlapalanca(a)gmail.com> wrote: > Hi list, > > How does one get the references to a class in Nautilus? In RB it used to be control+N, now I can't find it anywhere, not even in the context menus... > > Thanks! > > Bernat. > > -- > Bernat Romagosa.

March 13, 2013

Nautilus class references?

by Bernat Romagosa

Hi list, How does one get the references to a class in Nautilus? In RB it used to be control+N, now I can't find it anywhere, not even in the context menus... Thanks! Bernat. -- Bernat Romagosa.

March 13, 2013

Re: [Pharo-users] ZnWebSocket and Seaside ZnZincServerAdaptor

by Sven Van Caekenberghe

Hi Esteban, On 13 Mar 2013, at 03:15, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > Hi, > > Is there a way to use the same server Seaside is using to plug a > ZnWebSocketDelegate into it? > > The ZnZincServerAdaptor runs by default as the root delegator for its server > (at whatever port it was started), but I was wondering if there is a way to > reuse the same server Seaside (on top of Zinc) is using, to plug different > WS handlers. > > By now I'm just using another server to run the WS, which is no big deal > except to open an extra port in my server. > > Regards! I have several images that run multiple servers concurrently, especially separating the web socket stuff in a second server sounds like a good idea to me. By fiddling with different mappings in the default handler you can actually set up quite complex systems (like routes in other systems). But of course, there can only be one / handler. Regarding the Zinc Seaside Adaptor, some recent changes make it possible to run Seaside under /seaside instead of under /. ZnSeasideServerAdaptorDelegate>>installInServer: znServer underPrefix: prefix "Install a ZnSeasideServerAdaptorDelegate in znServer under prefix, provided znServer contains a ZnDefaultServerDelegate instance as primary delegate. Note that the incoming request is destructively modified." | seasideDelegate | seasideDelegate := self forServer: znServer. znServer delegate map: 'seaside' to: [ :request | request uri segments: request uri segments allButFirst. seasideDelegate handleRequest: request ]. ^ seasideDelegate Now execute the following line WAAdmin defaultDispatcher serverPath: prefix. And Seaside now works mostly as usual, including links and static files. There seem to be some links that don't work, but I guess that are actually bugs. Mind you, this is all a bit bleeding edge ;-) This might be interesting as well: http://forum.world.st/Running-ZnZincServerAdaptor-outside-WAServerManager-t… Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

March 13, 2013

Re: [Pharo-users] RFBServer>>#encryptPassword: wipes the password thats passed in and I'm confused why that's ok.

by Paul DeBruicker

On 03/12/2013 11:50 PM, Paul DeBruicker wrote: > IF I load the RFB package from lukas's site[1] (Pharo 1.4, recent enough > VM, linux) and set the RFB server's fullPassword like this: > > MyObject>>startRFB > RFBServer current setFullPassword: self rfbPassword > > MyObject>>rfbPassword > ^'1234' > > > After that send the source of rfbPassword shows '1234' but the bytecodes > show that it is '' and the apparently empty string is 8 bytes long with > each character being (Character value:0) > > > #setFullPassword: uses #atAllPut: to set the value of #rfbPassword to > 'Character value: 0'. > > My concerns are these: > > 1. Using the current implementation its impossible to stop and restart > the RFB server with a default password programmatically. > > 2. The implementation is not idempotent when starting/stopping. > > 3. I don't understand the security consequences of removing the part > where the password sent to #encryptPassword: is set to NULL characters. > > Is wiping the values of the #rfbPassword method necessary for security > reasons? I assume that setting the RFB server to only accept > connections from localhost and using X forwarding would take care of > most of the risk of having a string literal in the image. > > > Or- should I be accessing a default RFB password from another source > than a class side method in the image? > > Is there a standard practice for starting and stopping the RFB server in > Pharo 1.4 where the RFB server is up and down during the time the image > is up? > > > Thanks for any advice > > > Paul > > > > > 1 - The change was from this package: RFB-MiguelCoba.26.mcz from this > repo: http://source.lukas-renggli.ch/unsorted > Oh and if you want to see what I'm talking about load the latest from Lukas's site and run this RFBServer current inspect. pwd:='nintendo'. correctHash :=#[223 3 196 119 26 39 155 190]. 3 timesRepeat: [RFBServer current initializePreferences; configureForMemoryConservation; allowEmptyPasswords: false; allowRemoteConnections: false; yourself. RFBServer current setFullPassword: pwd. RFBServer current start: 1. RFBServer stop]. Then in the inspector check the value of the vncPassword inst var. The first value of the array should be #[223 3 196 119 26 39 155 190] if it were idempotent but is #[90 178 205 192 186 220 175 19] which is the hash value for an 8 byte NULL character password.

March 13, 2013

RFBServer>>#encryptPassword: wipes the password thats passed in and I'm confused why that's ok.

by Paul DeBruicker

IF I load the RFB package from lukas's site[1] (Pharo 1.4, recent enough VM, linux) and set the RFB server's fullPassword like this: MyObject>>startRFB RFBServer current setFullPassword: self rfbPassword MyObject>>rfbPassword ^'1234' After that send the source of rfbPassword shows '1234' but the bytecodes show that it is '' and the apparently empty string is 8 bytes long with each character being (Character value:0) #setFullPassword: uses #atAllPut: to set the value of #rfbPassword to 'Character value: 0'. My concerns are these: 1. Using the current implementation its impossible to stop and restart the RFB server with a default password programmatically. 2. The implementation is not idempotent when starting/stopping. 3. I don't understand the security consequences of removing the part where the password sent to #encryptPassword: is set to NULL characters. Is wiping the values of the #rfbPassword method necessary for security reasons? I assume that setting the RFB server to only accept connections from localhost and using X forwarding would take care of most of the risk of having a string literal in the image. Or- should I be accessing a default RFB password from another source than a class side method in the image? Is there a standard practice for starting and stopping the RFB server in Pharo 1.4 where the RFB server is up and down during the time the image is up? Thanks for any advice Paul 1 - The change was from this package: RFB-MiguelCoba.26.mcz from this repo: http://source.lukas-renggli.ch/unsorted

March 13, 2013

ZnWebSocket and Seaside ZnZincServerAdaptor

by Esteban A. Maringolo

Hi, Is there a way to use the same server Seaside is using to plug a ZnWebSocketDelegate into it? The ZnZincServerAdaptor runs by default as the root delegator for its server (at whatever port it was started), but I was wondering if there is a way to reuse the same server Seaside (on top of Zinc) is using, to plug different WS handlers. By now I'm just using another server to run the WS, which is no big deal except to open an extra port in my server. Regards! -- View this message in context: http://forum.world.st/ZnWebSocket-and-Seaside-ZnZincServerAdaptor-tp4676528… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

March 13, 2013

Re: [Pharo-users] about communication and collaboration

by Norbert Hartl

that's great! Another missing piece of the infrastructure! Nobert Am 12.03.2013 um 16:02 schrieb StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > Dear Pharoers > > last january I visited another lab and I realised that the Pharo Team was not good at systematically telling what we were doing. > I got quite frustrated by that situation, especially because we are working hard to build a better system. > So we brainstormed when I came back and we want to apply the same ideas that what we do for our research team. > > For our research team every monday we get a simple mail that tell us to say to the others what we did and what we > plan to do. Simple, easy. > Then after people of the rmod team can discuss if they want more. > > We want to do the same with pharo. > Often this is not that we are not doing things. Often we are doing boring, tedious stupid but $^%&&*^ important tasks and we want that you know it. > In addition we want to share on what we are weekly working. So that you can be more engaged to > join and collaborate with us. > > So we will launch an experience and see. For now we will send a notification every two weeks. > > the Pharo Team

March 12, 2013

Re: [Pharo-users] NeoCSV/NeoJSON and encodings

by Sven Van Caekenberghe

On 12 Mar 2013, at 20:38, "Esteban A. Maringolo" <emaringolo(a)gmail.com> wrote: > Hi all, Sven, > > Sorry I forgot to reply to this yesterday. > > It was simpler than anything else, for some reason I was using > StandardFileStream to read the file. I switched to FileStream and everything > went fine. Good! > ps: aString asFileReference writeStreamDo: doesn't work in my 1.4 image. ;-) I switched to 2.0 months ago, it so much nicer. -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

March 12, 2013

Re: [Pharo-users] NeoCSV/NeoJSON and encodings

by Esteban A. Maringolo

Hi all, Sven, Sorry I forgot to reply to this yesterday. It was simpler than anything else, for some reason I was using StandardFileStream to read the file. I switched to FileStream and everything went fine. ps: aString asFileReference writeStreamDo: doesn't work in my 1.4 image. -- View this message in context: http://forum.world.st/NeoCSV-NeoJSON-and-encodings-tp4676067p4676461.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

March 12, 2013