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

Re: [Pharo-users] Issue with UDP Sockets

by Manfred KrÃ¶hnert

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). > 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? Maybe nothing came back because the line ends where wrong ? > The lineendings I used are required by the SSDP specification. > 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

[ANN] Garage 0.2 - GarageGlorp - GarageConnectionPool

by Guillermo Polito

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 Guillermo Polito

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. 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'" 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 backporting) 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] Reopen last closed nautilus window

by merwanouddane＠gmail.com

Yes I know but it is not the same usage at all. Pharo allows me to adapt the system to my needs, thatâs what I am doing. De : Sergio Fedi EnvoyÃ© : âdimancheâ â17â âmaiâ â2015 â20â:â15 Ã : Any question about pharo is welcome Remember you can always make a window uncloseable. On Sun, May 17, 2015 at 3:03 PM, Merwan Ouddane <merwanouddane(a)gmail.com> wrote: Hello everyone, I always close some nautilus windows by mistake, and I that was really pissing me off... For people like me I made a little extension to reopen the last closed nautilus window with CTRL+MAJ+T or CMD+MAJ+T like most of internet browers (I know it erases the ifTrue: shortcut but I didn't wanted to have a shortcut who changes my habits...) Here is the repo: http://smalltalkhub.com/#!/~MerwanOuddane/NautilusSavior Cheers, Merwan

May 18, 2015

Re: [Pharo-users] Issue with UDP Sockets

by Sven Van Caekenberghe

Hi Manfred, Did you see/study the example/test UDPSocketEchoTest ? 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. 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. Maybe nothing came back because the line ends where wrong ? HTH, Sven > 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

Issue with UDP Sockets

by Manfred KrÃ¶hnert

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] Garage and SQLite file databases, general project structure

by Sven Van Caekenberghe

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] MagicMagritte Questions

by stepharo

I reloaded seaside to get the servers appear in the list. There is something strange there. stef > stepharo wrote >> Now I do not get why I only get a WATestServerAdaptor for the Seaside >> webserver. > I don't have an image handy, but IIRC the server(s) are in Zinc-Seaside. Let > me know if not... > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/MagicMagritte-Questions-tp4826857p4826904.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > > >

May 18, 2015

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

by Guillermo Polito

Hi Pierce, El sÃ¡b., 16 de may. de 2015 a la(s) 10:52 a. m., Pierce Ng < pierce(a)samadhiweb.com> escribiÃ³: > On Tue, May 12, 2015 at 08:35:23PM +0200, Torsten Bergmann wrote: > > Also I do not understand: while "Garage-Postgres" uses the Postgres > > project PostgresV2 as a backend the "Garage-Sqlite3" does not use > > NBSqlite3 or SQlite3 projects as backend. > > > > So "GASqlite3FFI" copies many methods of the original NBSQLite3 project > from > > Pierce and myself and is therefore like an own fork now. > > Yes, I agree this is not the best approach. I've just added support for > SQLite's online backup API to NBSQLite3. (See my blog.) Garage's forking > means > it does not directly benefit from improvements to NBSQLite3. Now, this > being > Smalltalk, I reckon that some metaprogramming magic will allow me to add > the > new stuff in NBSQLite3 to Garage, but overtime as the code bases diverge > this > gets difficult. > In general Garage will not benefit of sqlite specific features, because it should be as backend agnostic as possible. But as I said in the other email, maybe we could arrive to a packaging that suits both of us and decreases our efforts :). > > Pierce > >

May 18, 2015

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

by Guillermo Polito

Hi Torsten, Thanks for taking a look, I'll answer between lines :). El mar., 12 de may. de 2015 a la(s) 8:35 p. m., Torsten Bergmann < astares(a)gmx.de> escribiÃ³: > Hi Guille, > > I had a short look at Garage [1]. Nice initiative! > > Looks like using a file is not supported for the SQLite3 backend in Garage: > > GADriver fromConnectionString: 'sqlite3://file://C:/temp/test.db' > > GADriver fromConnectionString: 'sqlite3://C:/temp/test.db' > > > Maybe GASqlite3Driver>>fromConnectionString: could be adopted, but the > conversion to a Zn URL already removes some stuff. (Ab)using the schema in > the URL > as a driverID is nice - but prevents the use of file:// schema. > > How can one construct a file db? > 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. > Also I do not understand: while "Garage-Postgres" uses the Postgres > project PostgresV2 as a backend the "Garage-Sqlite3" does not use > NBSqlite3 or SQlite3 projects as backend. > Well, the main rationale behind this is that the public APIs of NBSqlite3 and Garage are not compatible while the one of Postgres is. I did not want to insert changes into NBSqlite3 that could break users. On the other hand, I could *patch* Postgres in the first version with some extension methods. Then, there are some other reasons/problems that bugged me: - I noticed while doing garage that even if the drivers are different in the very end, there are similarities in structure and code between them. And I wanted to reuse that code and put it into only one place instead of duplicate it for each driver, because it is easier to maintain. In that sense the Garage-Core driver is not just *an API* but has a bit of common behavior e.g., streaming of resultsets, some common superclasses. - Garage only needs its drivers to respect the common interface. I'd like to minimize special database features (unless unavoidable). In the case they already exist, I'd not like to publicize them as part of the Garage API because of obvious reasons. - A minor thing but that bothers me nonetheless: An alternative implementation would have been an adapting layer to communicate with the existing driver(s). This looked also as an overkill in maintenance. Also, some drivers such as mysql's was apparently not actively maintained so I would have to maintain a layer of adaptors and the driver itself. > So "GASqlite3FFI" copies many methods of the original NBSQLite3 project > from Pierce and myself > and is therefore like an own fork now. > Also the name FFI is misleading as it uses NativeBoost instead of FFI ... > > Yes, it's like a fork now. Maybe we can split it into another package so I can use it in garage easily? > Also it would be good if the project would be layered, we could have a > "Garage-Core" and "Garage-Tests-Core" with "Garage-Mysql" and > "Garage-Tests-Mysql" for > the fixtures. The idea is always to be able to load runtime code without > tests > for production code. > Well, if that is the desire of the majority, we can do it. For the moment I wanted to keep simple the metacello configurations also, so it was my trade-off to not split the packages for simplicity ^^. Thanks, and sorry for the long email, Guille

May 18, 2015