May 2015 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Issue with UDP Sockets

by Sven Van Caekenberghe

> On 18 May 2015, at 14:31, Ben Coman <btc(a)openinworld.com> wrote: > > > > On Mon, May 18, 2015 at 6:49 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > I meant that writing '\r\n' has no effect in Pharo, this is not processed (you could do this manually, of course). > > Is this something we should consider implementing to ease the way for newcomers? What downsides can you think of? > cheers -ben Nah, even in C, you need (s)printf for escape sequences to be interpreted. In any case, without error handling, this will do: | input escapes | escapes := { $n -> Character cr. $r -> Character lf. $\ -> $\ } asDictionary. input := 'foo\\bar\n\r'. String streamContents: [ :out | | in ch | in := input readStream. [ in atEnd ] whileFalse: [ ch := in next. ch = $\ ifTrue: [ out nextPut: (escapes at: in next) ] ifFalse: [ out nextPut: ch ] ] ] Sven

May 18, 2015

Re: [Pharo-users] Patterns for event handling Morphic?

by Stephan Eggermont

Thanks Alain. On 15-05-15 23:48, Alain Plantec via Pharo-users wrote: - HandleListenEvent: is for particular purpose, used rarely. I wonder about the way I'm using it. When drawing a connector between two shape morphs, I do the following: - I have a context menu on the shape, calling #connect MDShapeconnect |connector| connector := MDTempConnector from: self to: ActiveHand isBezier: false. connector openInWorld. When creating the MDTempConnector, I start listening to the hand's events MDTempConnector>>to: aHand to := aHand. ActiveHand addEventListener: self. MDTempConnector>>handleListenEvent: anEvent anEvent isMouse ifFalse: [ ^super handleListenEvent: anEvent]. anEvent isMouseUp ifTrue: [ self stopListening: anEvent]. anEvent isMouseMove ifTrue: [ self moved. self highlightShapeAt: anEvent ] And I stop listening on mouse up, possibly replacing the temporary one by a permanent one. MDTempConnector>>stopListening: anEvent ActiveHand removeEventListener: self. (self shapeAtPosition: anEvent) ifNotNil: [ :shape | from owner addMorphBack: (MDConnector from: from to: shape isBezier: smoothCurve) ]. over ifNotNil: [ over unhighlight ]. self delete Stephan

May 18, 2015

Re: [Pharo-users] Issue with UDP Sockets

by Ben Coman

On Mon, May 18, 2015 at 6:49 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > I meant that writing '\r\n' has no effect in Pharo, this is not processed > (you could do this manually, of course). Is this something we should consider implementing to ease the way for newcomers? What downsides can you think of? cheers -ben

May 18, 2015

Re: [Pharo-users] Is Smalltalkhub down ?

by Franck Warlouzet

It was. It is working now. > Date: Mon, 18 May 2015 13:39:22 +0200 > From: cyril.ferlicot(a)gmail.com > To: pharo-users(a)lists.pharo.org > Subject: Re: [Pharo-users] Is Smalltalkhub down ? > > Yeah > smalltalkhub is down ! > > On 18 May 2015 at 13:38, Thomas Heniart <heniart.thomas(a)gmail.com> wrote: > > Hi everyone, > > > > > > I can't access to Smalltalkhub (time out), is it the same for you? > > > > -- > Cheers > Cyril Ferlicot >

May 18, 2015

Re: [Pharo-users] Is Smalltalkhub down ?

by Cyril Ferlicot

Yeah smalltalkhub is down ! On 18 May 2015 at 13:38, Thomas Heniart <heniart.thomas(a)gmail.com> wrote: > Hi everyone, > > > I can't access to Smalltalkhub (time out), is it the same for you? -- Cheers Cyril Ferlicot

May 18, 2015

Is Smalltalkhub down ?

by Thomas Heniart

Hi everyone, I can't access to Smalltalkhub (time out), is it the same for you?

May 18, 2015

Re: [Pharo-users] [ANN] Garage 0.2 - GarageGlorp - GarageConnectionPool

by Sven Van Caekenberghe

Great work, thanks a lot ! > On 18 May 2015, at 12:27, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > Hi all, > > little announcement here. > > Updated Glorp v1.11 > ================ > I updated/merged latest configurations of Glorp with latest changes fixing TimeStamps and similar. I have fully green test cases in Pharo 5. > Latest version of the configuration is in Glorp's repository and copied to the corresponding MetaRepos. > > GarageGlorp v0.1 > ============= > A Garage extension to connect it to Glorp. All Glorp tests are green in Pharo3 and Pharo4. > > https://ci.inria.fr/dbxtalk/view/Garage-Glorp/ > http://guillep.github.io/DBXTalk/glorp.html > > Garage 0.2 > ======== > Some patches on Garage 0.1 were required to make garage glorp work. > - rows should be more polymorphic with arrays > - added isResultSet telling if the result of a query has rows > > Garage Connection Pool v0.1 > ====================== > A connection pool package featuring > - control of idle connections > - control of maximum connections to create > > http://guillep.github.io/DBXTalk/garage/connection_pooling.html > > Cheers, > Guille

May 18, 2015

Re: [Pharo-users] Garage and SQLite file databases, general project structure

by Sven Van Caekenberghe

> On 18 May 2015, at 12:13, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > Hi Sven, I'll take that into account. I did not think about using an empty host/port pair, maybe because of the extra slash. > > Also, I do not need to convert the file name to a file reference. That is done in sqlite by the sqlite library itself, so it's less work for the driver. The only need I need to do is: > - for nbsqlite get the file name > - for opendbx get the full file name and split into directory + file name because they are two different arguments for the library. I think that if you want to view (part of) a URL as a file system path and/or if you want to work with that path (splitting it directory/file for example), converting to a file reference is a good idea. ZnUrl can do file interpretation to some degree (#directory & #file, #isDirectoryPath & #isFilePath), but not very well (it is not its primary application). ZnUrl>>#path is actually not the best selector to use. It uses the internal representation. Like #directory & #file, #isDirectoryPath & #isFilePath, these leak some internals. ZnUrl>>#pathString is better, and will give you a leading $/ while encoding everything correctly. Also, relative File URLs simply do not exist. But there is #withRelativeReference: which follows the relevant specs (check the tests). FileReference should also deal better with platform issue, ZnURL is much more abstract, by definition. I hope this makes sense ;-) > Now, having a look at what we can do with znurl > > In windows it looks that we are ok > 'sqlite3:///c:/myDirectory/myfile.db' asUrl path. > "'c:/myDirectory/myfile.db'" > 'sqlite3:///c:\myDirectory\myfile.db' asUrl path. > "'c:\myDirectory\myfile.db'" See also #testWindowsDriveNamesInFileUrl > But in linux even if I put extra slashes it keeps removing them... And it makes difficult to recognize relative from absolute file paths: > > "Relative path c/myDirectory/myfile.db OK" > 'sqlite3:///c/myDirectory/myfile.db' asUrl path. > "'c/myDirectory/myfile.db'" > > "Absolute path /c/myDirectory/myfile.db not OK" > 'sqlite3:///c/myDirectory/myfile.db' asUrl path. > "'c/myDirectory/myfile.db'" > > Adding Slashes > 'sqlite3:////////c/myDirectory/myfile.db' asUrl path. > "'c/myDirectory/myfile.db'" > > Another concern is that garage as it is works in Pharo 3, 4 and 5. Then if we update Zn I'll have to add Zn to my dependencies and load the correct version accordingly, what do you think? (I prefer that to back porting) Just depend on the latest stable release of Zinc, it is (still) supported for 2.0 and up. > Guille > > > El lun., 18 de may. de 2015 a la(s) 11:27 a. m., Sven Van Caekenberghe <sven(a)stfx.eu> escribiÃ³: > Hi Guile, > > > On 18 May 2015, at 10:48, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > > > Well, I wanted in general to have a single easy-to-learn way to build a database connection string for all drivers. > > > > [driverid]://[host][:port]/[databasename]?[properties] > > > > Then, for sqlite I would like to have: > > > > sqlite3://myDirectory/myfile.db > > > > or > > > > sqlite3://memory > > > > Now, for Garage 0.1 I was using ZnUrl to parse the connection strings and that is not working for urls like the following because if the schema is not 'file' then the parser fails to to transform the port (an empty string in this case for the parser) to an integer > > > > sqlite3://c:/myDirectory/myfile.db > > > > In bleeding edge I am using an alternative parser that does no conversions and allows urls like that one. > > I understand the reasoning here, but I would suggest that you at least consider changing your mind. Over time, a lot of work went into ZnUrl, and many people used it and helped fixing many problems. Recently we tried to improve the situation for special schemes a bit (for git URLs). We're not yet there, but you (your use case) could help improving the situation. > > I tried to take a principled approach regarding the specs (not that there is one clear spec, haha), but edge cases should still be possible. > > Consider the following: > > 'postgresql://localhost:14433/test-db?username=john&password=123456' asUrl. > 'postgresql://john:123456@localhost:14433/test-db?encoding=utf8' asUrl. > 'postgresql://localhost/default' asUrl. > > 'sqlite3:///myDirectory/myfile.db' asUrl. > 'sqlite3://memory' asUrl. > 'sqlite3:///c:/myDirectory/myfile.db' asUrl. > > According to me, these all parse correctly. Of course, ZnUrl does not know or understand what is possibly special about any particular scheme (apart from HTTP(S)). Still, it is just an object that can be manipulated. > > The default port can be computed along the lines of #portOrDefault, maybe we could add a #portIfAbsent: ? > > Conversion to a file references can be done as follows: > > 'sqlite3:///c:/myDirectory/myfile.db' asUrl > copy scheme: #file; asFileReference. > > Which basically reads as: 'I know this is not a file:// URL proper, still I want to interpret it as if it were one'. Maybe we could add a #forceAsFileReference ? > > Anyway, you get the idea. You know I am willing to help. > > Sven > > > >

May 18, 2015

Re: [Pharo-users] Issue with UDP Sockets

by Manfred KrÃ¶hnert

Thanks for the explanation. Best, Manfred On Mon, May 18, 2015 at 12:49 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > On 18 May 2015, at 12:44, Manfred KrÃ¶hnert <mkroehnert42(a)googlemail.com> > wrote: > > > > Hello Sven, > > > > thanks for your fast reply. > > > > On Mon, May 18, 2015 at 11:41 AM, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > > Hi Manfred, > > > > Did you see/study the example/test UDPSocketEchoTest ? > > > > unfortunately I did not see this class, yet. > > But I did look at the Socket class itself and Socket>>timeTestUDP (in > Pharo3). > > We removed #timeTestUDP in Pharo 4 and higher, I believe, and replaced it > with proper tests/examples. > > > Also, UDP is very primitive: it is send and forget, returns no errors, > and is totally asynchronous. Listening should best be done in a separate > process. > > > > Yes, UDP is primitive but the SSDP specification requires using UDP. > > > > Here is how I would write your send part: > > > > | message udpSocket | > > message := String crlf join: #( > > 'M-SEARCH * HTTP/1.1' > > 'HOST:239.255.255.250:1900' > > 'MAN:"ssdp:discover' > > 'ST:ssdp:all' > > 'MX:1' > > ''). > > > > udpSocket := Socket newUDP. > > udpSocket sendData: message toHost: #[239 255 255 250] port: 1900. > > udpSocket waitForSendDoneFor: 5. > > udpSocket closeAndDestroy. > > > > Thanks for this snippet. > > For some reasons I do not understand yet, this gives me the expected > result in contrast to my own version. > > > > I modified it like this to print the results on the Transcript: > > > > | message udpSocket | > > message := String crlf join: #( > > 'M-SEARCH * HTTP/1.1' > > 'HOST:239.255.255.250:1900' > > 'MAN:"ssdp:discover"' > > 'ST:ssdp:all' > > 'MX:1' > > ''). > > > > udpSocket := Socket newUDP. > > udpSocket sendData: message toHost: #[239 255 255 250] port: 1900. > > udpSocket waitForSendDoneFor: 5. > > udpSocket waitForData. > > [udpSocket dataAvailable ] whileTrue: [ | buffer | > > buffer := ByteArray new: 1024. > > udpSocket receiveUDPDataInto: buffer. > > Transcript show: 'Received: ', buffer. > > [udpSocket waitForDataFor: 1] on: Error do: [ ]. > > ]. > > udpSocket closeAndDestroy. > > > > Currently, this will work for me, since I am not interested in > continuously detecting new devices. > > But you mentioned reading should in general be done in a separate > process. > > Would you reuse the existing udpSocket instance in this case or create a > separate one for reading? > > I think if it is only for a one time use, it is OK like you are doing it. > > > Maybe nothing came back because the line ends where wrong ? > > > > The lineendings I used are required by the SSDP specification. > > I meant that writing '\r\n' has no effect in Pharo, this is not processed > (you could do this manually, of course). This is why I did it with the > #join: > > That is the difference and why it works now, I guess. > > > HTH, > > > > Sven > > > > Thanks, > > Manfred > > > > > On 18 May 2015, at 11:29, Manfred KrÃ¶hnert < > mkroehnert42(a)googlemail.com> wrote: > > > > > > Hello everyone, > > > > > > I am currently trying to get a list of UPnP device via SSDP (Simple > Service Discovery Protocol). > > > > > > A minimalistic working NodeJS example looks like this: > > > > > > var dgram = require('dgram'); > > > var message = new Buffer( > > > "M-SEARCH * HTTP/1.1\r\n" + > > > "HOST:239.255.255.250:1900\r\n" + > > > "MAN:\"ssdp:discover\"\r\n" + > > > "ST:ssdp:all\r\n" + > > > "MX:1\r\n" + > > > "\r\n" > > > ); > > > > > > var client = dgram.createSocket("udp4"); > > > > > > client.on("message", function (msg, rinfo) { > > > console.log("server got: " + msg + " from " + rinfo.address + > ":" + rinfo.port); > > > }); > > > client.send(message, 0, message.length, 1900, "239.255.255.250"); > > > client.close(); > > > > > > I tried to recreate the same functionality in Pharo with the following > piece of code: > > > > > > | message udpSocket host | > > > message := 'M-SEARCH * HTTP/1.1\r\n' , > > > 'HOST:239.255.255.250:1900\r\n' , > > > 'MAN:"ssdp:discover"\r\n' , > > > 'ST:ssdp:all\r\n' , > > > 'MX:1\r\n' , '\r\n'. > > > > > > udpSocket := Socket newUDP. > > > host := (NetNameResolver addressFromString: '239.255.255.250'). > > > udpSocket sendData: message toHost: host port: 1900. > > > "udpSocket waitForData." > > > Transcript show: 'Received: ' , udpSocket receiveData. > > > udpSocket closeAndDestroy. > > > > > > Unfortunately, this script hangs both in Pharo3 and Pharo4 (OS X > 10.10, Pharo 30856 and 40611). > > > When I interrupt with Cmd+. the debugger shows the method > > > Socket>>waitForDataIfClosed: > > > and the hang is apparently in the line > > > self readSemaphore wait > > > > > > Could anyone give me some advice if I should to do this differently or > what the issue with the Pharo script is? > > > > > > Thanks in advance, > > > Manfred > > > > > > > > >

May 18, 2015

Re: [Pharo-users] Issue with UDP Sockets

by Sven Van Caekenberghe

> On 18 May 2015, at 12:44, Manfred KrÃ¶hnert <mkroehnert42(a)googlemail.com> wrote: > > Hello Sven, > > thanks for your fast reply. > > On Mon, May 18, 2015 at 11:41 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi Manfred, > > Did you see/study the example/test UDPSocketEchoTest ? > > unfortunately I did not see this class, yet. > But I did look at the Socket class itself and Socket>>timeTestUDP (in Pharo3). We removed #timeTestUDP in Pharo 4 and higher, I believe, and replaced it with proper tests/examples. > Also, UDP is very primitive: it is send and forget, returns no errors, and is totally asynchronous. Listening should best be done in a separate process. > > Yes, UDP is primitive but the SSDP specification requires using UDP. > > Here is how I would write your send part: > > | message udpSocket | > message := String crlf join: #( > 'M-SEARCH * HTTP/1.1' > 'HOST:239.255.255.250:1900' > 'MAN:"ssdp:discover' > 'ST:ssdp:all' > 'MX:1' > ''). > > udpSocket := Socket newUDP. > udpSocket sendData: message toHost: #[239 255 255 250] port: 1900. > udpSocket waitForSendDoneFor: 5. > udpSocket closeAndDestroy. > > Thanks for this snippet. > For some reasons I do not understand yet, this gives me the expected result in contrast to my own version. > > I modified it like this to print the results on the Transcript: > > | message udpSocket | > message := String crlf join: #( > 'M-SEARCH * HTTP/1.1' > 'HOST:239.255.255.250:1900' > 'MAN:"ssdp:discover"' > 'ST:ssdp:all' > 'MX:1' > ''). > > udpSocket := Socket newUDP. > udpSocket sendData: message toHost: #[239 255 255 250] port: 1900. > udpSocket waitForSendDoneFor: 5. > udpSocket waitForData. > [udpSocket dataAvailable ] whileTrue: [ | buffer | > buffer := ByteArray new: 1024. > udpSocket receiveUDPDataInto: buffer. > Transcript show: 'Received: ', buffer. > [udpSocket waitForDataFor: 1] on: Error do: [ ]. > ]. > udpSocket closeAndDestroy. > > Currently, this will work for me, since I am not interested in continuously detecting new devices. > But you mentioned reading should in general be done in a separate process. > Would you reuse the existing udpSocket instance in this case or create a separate one for reading? I think if it is only for a one time use, it is OK like you are doing it. > Maybe nothing came back because the line ends where wrong ? > > The lineendings I used are required by the SSDP specification. I meant that writing '\r\n' has no effect in Pharo, this is not processed (you could do this manually, of course). This is why I did it with the #join: That is the difference and why it works now, I guess. > HTH, > > Sven > > Thanks, > Manfred > > > On 18 May 2015, at 11:29, Manfred KrÃ¶hnert <mkroehnert42(a)googlemail.com> wrote: > > > > Hello everyone, > > > > I am currently trying to get a list of UPnP device via SSDP (Simple Service Discovery Protocol). > > > > A minimalistic working NodeJS example looks like this: > > > > var dgram = require('dgram'); > > var message = new Buffer( > > "M-SEARCH * HTTP/1.1\r\n" + > > "HOST:239.255.255.250:1900\r\n" + > > "MAN:\"ssdp:discover\"\r\n" + > > "ST:ssdp:all\r\n" + > > "MX:1\r\n" + > > "\r\n" > > ); > > > > var client = dgram.createSocket("udp4"); > > > > client.on("message", function (msg, rinfo) { > > console.log("server got: " + msg + " from " + rinfo.address + ":" + rinfo.port); > > }); > > client.send(message, 0, message.length, 1900, "239.255.255.250"); > > client.close(); > > > > I tried to recreate the same functionality in Pharo with the following piece of code: > > > > | message udpSocket host | > > message := 'M-SEARCH * HTTP/1.1\r\n' , > > 'HOST:239.255.255.250:1900\r\n' , > > 'MAN:"ssdp:discover"\r\n' , > > 'ST:ssdp:all\r\n' , > > 'MX:1\r\n' , '\r\n'. > > > > udpSocket := Socket newUDP. > > host := (NetNameResolver addressFromString: '239.255.255.250'). > > udpSocket sendData: message toHost: host port: 1900. > > "udpSocket waitForData." > > Transcript show: 'Received: ' , udpSocket receiveData. > > udpSocket closeAndDestroy. > > > > Unfortunately, this script hangs both in Pharo3 and Pharo4 (OS X 10.10, Pharo 30856 and 40611). > > When I interrupt with Cmd+. the debugger shows the method > > Socket>>waitForDataIfClosed: > > and the hang is apparently in the line > > self readSemaphore wait > > > > Could anyone give me some advice if I should to do this differently or what the issue with the Pharo script is? > > > > Thanks in advance, > > Manfred > > >

May 18, 2015