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

Re: [Pharo-users] Alt-tab between windows

by jtuchel＠objektfabrik.de

Avdi, I wrote a series of articles on th etopic back in 2009: you can find the first article here: https://joachimtuchel.wordpress.com/2009/07/02/whats-in-a-smalltalk-browser… Back then, I tried to share my thoughts on what I think A Smalltalk IDE should look like these days (well, those days ;-) ). I've seen some of the ideas presented and taken further at ESUG/IWST talks over the years, some of which I really liked, but - as far as I can tell - none of these projects went anywhere. None of the commercial vendors made any attempts to work on window clutter or streamlining their IDEs. Smalltalk Browsers are still the same as they were in 1981, all that's been added is a little bit of colourful button bars here and there and tabbing (most implementations even managed to get that wrong). I think the conclusion I came to was that a Smalltalk IDE has two main tasks: navgating code and editing code Actually three: debugging which adds some stuff on top of the other two. I think we all can agree on that Smalltalk's editing facilities mostly sucked for decades. The lame excuse was that real Smalltalkers write methods of no more than 6 lines. Fortnunately, we seem to have accepted that either the assumption about real Smalltalkers was wrong or that even 6 lines of code are worth syntax highlighting, code completion and all kinds of assistance for the developer. I also think that navigating code is extremely important. The fact that each browser comes with its own navigation area that takes up about 50 percent of the real estate of the browser, however, is just plain wrong. We are missing clever navigation facilities in Smalltalk. I think the GT Tools are a great start in improving things and they are much better than anything we have had for 40 years now, but it is just a step on a long stairway. Other Smalltalk implementations literally have nothing in this area that wasn't there in the 80ies. On the other hand, what Smalltalk has offered for code navigation and retrieval in the 80ies, was about 25-30 years ahead of the mainstream. So I am not saying Smalltalk's environment is bad per se. It could just be a lot better if more research or experimentation was done in the area. The GT tools show that it is worth it and can boost Smalltalk developers' productivity a lot. Joachim Am 19.05.15 um 01:08 schrieb Avdi Grimm: > > On Sat, May 16, 2015 at 4:23 PM, jtuchel(a)objektfabrik.de > <mailto:jtuchel@objektfabrik.de> <jtuchel(a)objektfabrik.de > <mailto:jtuchel@objektfabrik.de>> wrote: > > I mostly work in other Smalltalk environments than Pharo, like VA > Smalltalk. It has native windows and so the ability to switch > between windows using alt-tab is there. I must admit that there is > a certain threshold in the number of open windows when this is not > really helpful any more. I tend to hit that number pretty fast in > a typical Smalltalk coding/debugging sessions. > > Things have changed in Win 7, because there I can use the window > manager to close the windows right in the window switcher. That > makes perfect sense if you have 15 inspectors open, none of which > shows current data or instances any more. Or if one of them does, > I can't decide which one ;-) > > So sometimes I wish for features like "close all windows of this > kind" to kill all inspectors, for example. > > What I want to say with this that I am not really using alt-tab to > switch between windows, but rather to kill a few to come down to a > sensible number ;-) But I understand why you miss it. For Pharo, > there is a special problem: it is its own windowing environment, > so it should probably better not use the O/S' key combination to > switch its windows, right? > > > Just as some food for thought for anyone contemplating this problem: > > Sometimes problems like this are indicative of deeper usability > issues. Decades ago, it was just sort of assumed that the "right" way > to deal with windows was to have a dedicated window for every "thing" > in your system. To some degree, Mac OS, Wind95, and OS/2 all took this > point of view. For instance, every folder you double-clicked on would > open up a new file manager window, and this got to be such a mess that > some OSes included "secret" shortcuts for killing them all at once. > > Then the web started to take off, and UX designers started rethinking > the whole paradigm. They started keeping things in the same window, > but adding back/forward buttons, and navigation histories, and > sidebars, and address bars, and tabs, and other affordances to make it > easier to switch between "things" without necessarily adding more windows. > > These days, most IDEs and editors have followed suit. I can't think of > a single editor in common use among the programmers I know which > encourages multiple windows. Whether it's Vim, Emacs, Sublime, > IntelliJ, while you *can* open lots of windows if you really want to, > they all focus on making it easy to manage lots of buffers in a single > window rather than encouraging lots of windows. > > Personally, I'm a fan of this trend. I'm much happier typing a few > characters to auto-complete the buffer I want to return to in Emacs, > than I am hunting around in an OS window list for it. > > This is all a long-winded way of saying: just because this is > currently a problem, doesn't mean it's the *right* problem. It would > be interesting to see what a "fewer windows" approach to Smalltalk > development might look like. > > -- > Avdi Grimm > http://avdi.org > -- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

May 19, 2015

Re: [Pharo-users] Alt-tab between windows

by Ben Coman

On Tue, May 19, 2015 at 7:08 AM, Avdi Grimm <avdi(a)avdi.org> wrote: > > On Sat, May 16, 2015 at 4:23 PM, jtuchel(a)objektfabrik.de < > jtuchel(a)objektfabrik.de> wrote: > >> I mostly work in other Smalltalk environments than Pharo, like VA >> Smalltalk. It has native windows and so the ability to switch between >> windows using alt-tab is there. I must admit that there is a certain >> threshold in the number of open windows when this is not really helpful any >> more. I tend to hit that number pretty fast in a typical Smalltalk >> coding/debugging sessions. >> >> Things have changed in Win 7, because there I can use the window manager >> to close the windows right in the window switcher. That makes perfect sense >> if you have 15 inspectors open, none of which shows current data or >> instances any more. Or if one of them does, I can't decide which one ;-) >> >> So sometimes I wish for features like "close all windows of this kind" to >> kill all inspectors, for example. >> >> What I want to say with this that I am not really using alt-tab to switch >> between windows, but rather to kill a few to come down to a sensible number >> ;-) But I understand why you miss it. For Pharo, there is a special >> problem: it is its own windowing environment, so it should probably better >> not use the O/S' key combination to switch its windows, right? >> > > Just as some food for thought for anyone contemplating this problem: > > Sometimes problems like this are indicative of deeper usability issues. > Decades ago, it was just sort of assumed that the "right" way to deal with > windows was to have a dedicated window for every "thing" in your system. To > some degree, Mac OS, Wind95, and OS/2 all took this point of view. For > instance, every folder you double-clicked on would open up a new file > manager window, and this got to be such a mess that some OSes included > "secret" shortcuts for killing them all at once. > > Then the web started to take off, and UX designers started rethinking the > whole paradigm. They started keeping things in the same window, but adding > back/forward buttons, and navigation histories, and sidebars, and address > bars, and tabs, and other affordances to make it easier to switch between > "things" without necessarily adding more windows. > > These days, most IDEs and editors have followed suit. I can't think of a > single editor in common use among the programmers I know which encourages > multiple windows. Whether it's Vim, Emacs, Sublime, IntelliJ, while you > *can* open lots of windows if you really want to, they all focus on making > it easy to manage lots of buffers in a single window rather than > encouraging lots of windows. > > Personally, I'm a fan of this trend. I'm much happier typing a few > characters to auto-complete the buffer I want to return to in Emacs, than I > am hunting around in an OS window list for it. > > This is all a long-winded way of saying: just because this is currently a > problem, doesn't mean it's the *right* problem. It would be interesting to > see what a "fewer windows" approach to Smalltalk development might look > like. > > This is an interesting UI area to explore. As a step in this direction, the Window Menu (small arrow in title bar) item "Create window group" may provide part of the behaviour you are looking for. cheers -ben

May 19, 2015

Re: [Pharo-users] Issue with UDP Sockets

by Ben Coman

Ultimate fallback, use Wireshark to compare packets on the wire between using node.js and Pharo. http://en.wikiversity.org/wiki/Wireshark/IPv4_multicast cheers -ben On Tue, May 19, 2015 at 6:17 AM, Udo Schneider <udo.schneider(a)homeaddress.de > wrote: > This should have been 'IP_ADD_MEMBERSHIP' of course: > > imrMultiaddr := #[239 255 255 250]. > imrInterface := #[0 0 0 0]. > ipMreq := imrMultiaddr , imrInterface. > socket setOption: 'IP_ADD_MEMBERSHIP' value: ipMreq. > > > The "server" could be something like this (execute in first playground). I > used another IP address (#[239 255 255 251]) because #[239 255 255 250] > might already be part of the multicast group because of other processes and > this shows the "whole" process of subscribing to a multicast group: > > [ > | udpSocket | > udpSocket := Socket newUDP. > udpSocket setPort: 1900. > imrMultiaddr := #[239 255 255 251]. > imrInterface := #[0 0 0 0]. > ipMreq := imrMultiaddr , imrInterface. > udpSocket setOption: 'IP_ADD_MEMBERSHIP' value: ipMreq. > udpSocket setOption: 'IP_MULTICAST_LOOP' value: 1. > "udpSocket setOption: 'SO_REUSEADDR' value: 1." > udpSocket waitForData. > buffer := ByteArray new: 256. > data := udpSocket receiveUDPDataInto: buffer. > bytesRead := data at: 1. > sender := data at: 2. > senderPort := data at: 3. > more := data at: 4. > result := buffer copyFrom: 1 to: bytesRead. > udpSocket closeAndDestroy. > result asString inspect. > ] fork. > > > > The "client" (execute in different playground): > | 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 251] port: 1900. > (udpSocket waitForSendDoneFor: 5). > udpSocket closeAndDestroy. > > Hope this helps. > > CU, > > Udo > > > > > > > On 18/05/15 23:29, Udo Schneider wrote: > >> Hi Manfred, >> >> I just stumbled over the IP address you are using (239.255.255.250). If >> I remember correctly this is a IPv4 Class D Multicast address. >> (224.0.0.0-239.255.255.255). >> >> So if you want to transmit datagrams to this IP address or recieve >> datagrams sent to this multicast groups you have to set appropriate IP >> Options. >> >> You can set this options using Socket>>#setOption:value: and read them >> using Socket>>#getOption:. Please note that both methods expect the >> option to set as a name - not as constant. E.g. >> >> socket setOption: 'IP_MULTICAST_IF' value: multicastInterface. >> >> If I do remember correctly you have to set the following options for >> sending/receiving: >> >> Sending: >> IP_MULTICAST_IF >> (IP_MULTICAST_LOOP) >> (IP_MULTICAST_TTL) >> >> Sending should AFAIK work w/o setting any option - although >> IP_MULTICAST_IF is highly recommended. >> >> Receiving: >> (SO_REUSEADDR) >> IP_ADD_MEMBERSHIP >> (IP_DROP_MEMBERSHIP) >> >> Receiving only works if you joined the multicast group previously. So I >> assume that you need to do something like this (not tested). >> >> imrMultiaddr := #[239 255 255 250]. >> imrInterface := #[0 0 0 0]. >> ipMreq := imrMultiaddr , imrInterface. >> socket setOption: 'MEMBERSHIP' value: ipMreq. >> >> Hope this helps. >> >> CU, >> >> Udo >> >> >> >> On 18/05/15 16:34, Manfred KrÃ¶hnert wrote: >> >>> Hi Sven, >>> >>> On Mon, May 18, 2015 at 4:14 PM, Sven Van Caekenberghe >>> <sven(a)stfx.eu >>> <mailto:sven@stfx.eu>> wrote: >>> >>> >>> > On 18 May 2015, at 15:47, Manfred KrÃ¶hnert >>> <mkroehnert42(a)googlemail.com >>> <mailto:mkroehnert42@googlemail.com>> wrote: >>> > >>> > Hi, >>> > apparently I am missing something else. >>> > >>> > I can find devices when connected to a 'regular' LAN. >>> > >>> > However, I have a camera that creates a Wifi accesspoint and >>> makes itself discoverable via SSDP. >>> > Once I connect to this accesspoint my computer gets a valid IP >>> address assigned and the NodeJS code is able to discover the device. >>> > Unfortunately, the Pharo snippet I posted before does not give me >>> any results and hangs in Socket>>waitForDataIfClosed: . >>> > >>> > Any further ideas? >>> >>> Are you sure you restarted the image and your code after switching >>> networks ? >>> >>> >>> I did not check this before. >>> But I just downloaded a fresh 40613 image with PharoLauncher and started >>> it after connecting to the camera accesspoint. >>> The code snippet freezes there as well. >>> >>> Manfred >>> >> >> >> >> >> > > >

May 19, 2015

Re: [Pharo-users] Alt-tab between windows

by Avdi Grimm

On Sat, May 16, 2015 at 4:23 PM, jtuchel(a)objektfabrik.de < jtuchel(a)objektfabrik.de> wrote: > I mostly work in other Smalltalk environments than Pharo, like VA > Smalltalk. It has native windows and so the ability to switch between > windows using alt-tab is there. I must admit that there is a certain > threshold in the number of open windows when this is not really helpful any > more. I tend to hit that number pretty fast in a typical Smalltalk > coding/debugging sessions. > > Things have changed in Win 7, because there I can use the window manager > to close the windows right in the window switcher. That makes perfect sense > if you have 15 inspectors open, none of which shows current data or > instances any more. Or if one of them does, I can't decide which one ;-) > > So sometimes I wish for features like "close all windows of this kind" to > kill all inspectors, for example. > > What I want to say with this that I am not really using alt-tab to switch > between windows, but rather to kill a few to come down to a sensible number > ;-) But I understand why you miss it. For Pharo, there is a special > problem: it is its own windowing environment, so it should probably better > not use the O/S' key combination to switch its windows, right? > Just as some food for thought for anyone contemplating this problem: Sometimes problems like this are indicative of deeper usability issues. Decades ago, it was just sort of assumed that the "right" way to deal with windows was to have a dedicated window for every "thing" in your system. To some degree, Mac OS, Wind95, and OS/2 all took this point of view. For instance, every folder you double-clicked on would open up a new file manager window, and this got to be such a mess that some OSes included "secret" shortcuts for killing them all at once. Then the web started to take off, and UX designers started rethinking the whole paradigm. They started keeping things in the same window, but adding back/forward buttons, and navigation histories, and sidebars, and address bars, and tabs, and other affordances to make it easier to switch between "things" without necessarily adding more windows. These days, most IDEs and editors have followed suit. I can't think of a single editor in common use among the programmers I know which encourages multiple windows. Whether it's Vim, Emacs, Sublime, IntelliJ, while you *can* open lots of windows if you really want to, they all focus on making it easy to manage lots of buffers in a single window rather than encouraging lots of windows. Personally, I'm a fan of this trend. I'm much happier typing a few characters to auto-complete the buffer I want to return to in Emacs, than I am hunting around in an OS window list for it. This is all a long-winded way of saying: just because this is currently a problem, doesn't mean it's the *right* problem. It would be interesting to see what a "fewer windows" approach to Smalltalk development might look like. -- Avdi Grimm http://avdi.org

May 18, 2015

Re: [Pharo-users] Issue with UDP Sockets

by Udo Schneider

This should have been 'IP_ADD_MEMBERSHIP' of course: imrMultiaddr := #[239 255 255 250]. imrInterface := #[0 0 0 0]. ipMreq := imrMultiaddr , imrInterface. socket setOption: 'IP_ADD_MEMBERSHIP' value: ipMreq. The "server" could be something like this (execute in first playground). I used another IP address (#[239 255 255 251]) because #[239 255 255 250] might already be part of the multicast group because of other processes and this shows the "whole" process of subscribing to a multicast group: [ | udpSocket | udpSocket := Socket newUDP. udpSocket setPort: 1900. imrMultiaddr := #[239 255 255 251]. imrInterface := #[0 0 0 0]. ipMreq := imrMultiaddr , imrInterface. udpSocket setOption: 'IP_ADD_MEMBERSHIP' value: ipMreq. udpSocket setOption: 'IP_MULTICAST_LOOP' value: 1. "udpSocket setOption: 'SO_REUSEADDR' value: 1." udpSocket waitForData. buffer := ByteArray new: 256. data := udpSocket receiveUDPDataInto: buffer. bytesRead := data at: 1. sender := data at: 2. senderPort := data at: 3. more := data at: 4. result := buffer copyFrom: 1 to: bytesRead. udpSocket closeAndDestroy. result asString inspect. ] fork. The "client" (execute in different playground): | 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 251] port: 1900. (udpSocket waitForSendDoneFor: 5). udpSocket closeAndDestroy. Hope this helps. CU, Udo On 18/05/15 23:29, Udo Schneider wrote: > Hi Manfred, > > I just stumbled over the IP address you are using (239.255.255.250). If > I remember correctly this is a IPv4 Class D Multicast address. > (224.0.0.0-239.255.255.255). > > So if you want to transmit datagrams to this IP address or recieve > datagrams sent to this multicast groups you have to set appropriate IP > Options. > > You can set this options using Socket>>#setOption:value: and read them > using Socket>>#getOption:. Please note that both methods expect the > option to set as a name - not as constant. E.g. > > socket setOption: 'IP_MULTICAST_IF' value: multicastInterface. > > If I do remember correctly you have to set the following options for > sending/receiving: > > Sending: > IP_MULTICAST_IF > (IP_MULTICAST_LOOP) > (IP_MULTICAST_TTL) > > Sending should AFAIK work w/o setting any option - although > IP_MULTICAST_IF is highly recommended. > > Receiving: > (SO_REUSEADDR) > IP_ADD_MEMBERSHIP > (IP_DROP_MEMBERSHIP) > > Receiving only works if you joined the multicast group previously. So I > assume that you need to do something like this (not tested). > > imrMultiaddr := #[239 255 255 250]. > imrInterface := #[0 0 0 0]. > ipMreq := imrMultiaddr , imrInterface. > socket setOption: 'MEMBERSHIP' value: ipMreq. > > Hope this helps. > > CU, > > Udo > > > > On 18/05/15 16:34, Manfred KrÃ¶hnert wrote: >> Hi Sven, >> >> On Mon, May 18, 2015 at 4:14 PM, Sven Van Caekenberghe >> <sven(a)stfx.eu >> <mailto:sven@stfx.eu>> wrote: >> >> >> > On 18 May 2015, at 15:47, Manfred KrÃ¶hnert >> <mkroehnert42(a)googlemail.com >> <mailto:mkroehnert42@googlemail.com>> wrote: >> > >> > Hi, >> > apparently I am missing something else. >> > >> > I can find devices when connected to a 'regular' LAN. >> > >> > However, I have a camera that creates a Wifi accesspoint and >> makes itself discoverable via SSDP. >> > Once I connect to this accesspoint my computer gets a valid IP >> address assigned and the NodeJS code is able to discover the device. >> > Unfortunately, the Pharo snippet I posted before does not give me >> any results and hangs in Socket>>waitForDataIfClosed: . >> > >> > Any further ideas? >> >> Are you sure you restarted the image and your code after switching >> networks ? >> >> >> I did not check this before. >> But I just downloaded a fresh 40613 image with PharoLauncher and started >> it after connecting to the camera accesspoint. >> The code snippet freezes there as well. >> >> Manfred > > > >

May 18, 2015

Re: [Pharo-users] Issue with UDP Sockets

by Manfred KrÃ¶hnert

Hello Udo, thanks for your detailed reply. I am going to try your suggestions and report back afterwards. Not sure though if I get to try it before next weekend. The address I am sending to is definitely a multi-cast address (as defined in the SSDP spec). But what makes me wonder is why the minimal NodeJS example works in both cases without modifications (regular router/accesspoint + camera accesspoint) and the Pharo one only receives data in the first case. But maybe there is something happening behind the curtains in NodeJS when it comes to multi-cast addresses. Thanks, Manfred On Mon, May 18, 2015 at 11:29 PM, Udo Schneider < udo.schneider(a)homeaddress.de> wrote: > Hi Manfred, > > I just stumbled over the IP address you are using (239.255.255.250). If I > remember correctly this is a IPv4 Class D Multicast address. > (224.0.0.0-239.255.255.255). > > So if you want to transmit datagrams to this IP address or recieve > datagrams sent to this multicast groups you have to set appropriate IP > Options. > > You can set this options using Socket>>#setOption:value: and read them > using Socket>>#getOption:. Please note that both methods expect the option > to set as a name - not as constant. E.g. > > socket setOption: 'IP_MULTICAST_IF' value: multicastInterface. > > If I do remember correctly you have to set the following options for > sending/receiving: > > Sending: > IP_MULTICAST_IF > (IP_MULTICAST_LOOP) > (IP_MULTICAST_TTL) > > Sending should AFAIK work w/o setting any option - although > IP_MULTICAST_IF is highly recommended. > > Receiving: > (SO_REUSEADDR) > IP_ADD_MEMBERSHIP > (IP_DROP_MEMBERSHIP) > > Receiving only works if you joined the multicast group previously. So I > assume that you need to do something like this (not tested). > > imrMultiaddr := #[239 255 255 250]. > imrInterface := #[0 0 0 0]. > ipMreq := imrMultiaddr , imrInterface. > socket setOption: 'MEMBERSHIP' value: ipMreq. > > Hope this helps. > > CU, > > Udo > > > > On 18/05/15 16:34, Manfred KrÃ¶hnert wrote: > >> Hi Sven, >> >> On Mon, May 18, 2015 at 4:14 PM, Sven Van Caekenberghe >> <sven(a)stfx.eu >> <mailto:sven@stfx.eu>> wrote: >> >> >> > On 18 May 2015, at 15:47, Manfred KrÃ¶hnert >> <mkroehnert42(a)googlemail.com >> <mailto:mkroehnert42@googlemail.com>> wrote: >> > >> > Hi, >> > apparently I am missing something else. >> > >> > I can find devices when connected to a 'regular' LAN. >> > >> > However, I have a camera that creates a Wifi accesspoint and >> makes itself discoverable via SSDP. >> > Once I connect to this accesspoint my computer gets a valid IP >> address assigned and the NodeJS code is able to discover the device. >> > Unfortunately, the Pharo snippet I posted before does not give me >> any results and hangs in Socket>>waitForDataIfClosed: . >> > >> > Any further ideas? >> >> Are you sure you restarted the image and your code after switching >> networks ? >> >> >> I did not check this before. >> But I just downloaded a fresh 40613 image with PharoLauncher and started >> it after connecting to the camera accesspoint. >> The code snippet freezes there as well. >> >> Manfred >> > > > >

May 18, 2015

Re: [Pharo-users] Issue with UDP Sockets

by Udo Schneider

Hi Manfred, I just stumbled over the IP address you are using (239.255.255.250). If I remember correctly this is a IPv4 Class D Multicast address. (224.0.0.0-239.255.255.255). So if you want to transmit datagrams to this IP address or recieve datagrams sent to this multicast groups you have to set appropriate IP Options. You can set this options using Socket>>#setOption:value: and read them using Socket>>#getOption:. Please note that both methods expect the option to set as a name - not as constant. E.g. socket setOption: 'IP_MULTICAST_IF' value: multicastInterface. If I do remember correctly you have to set the following options for sending/receiving: Sending: IP_MULTICAST_IF (IP_MULTICAST_LOOP) (IP_MULTICAST_TTL) Sending should AFAIK work w/o setting any option - although IP_MULTICAST_IF is highly recommended. Receiving: (SO_REUSEADDR) IP_ADD_MEMBERSHIP (IP_DROP_MEMBERSHIP) Receiving only works if you joined the multicast group previously. So I assume that you need to do something like this (not tested). imrMultiaddr := #[239 255 255 250]. imrInterface := #[0 0 0 0]. ipMreq := imrMultiaddr , imrInterface. socket setOption: 'MEMBERSHIP' value: ipMreq. Hope this helps. CU, Udo On 18/05/15 16:34, Manfred KrÃ¶hnert wrote: > Hi Sven, > > On Mon, May 18, 2015 at 4:14 PM, Sven Van Caekenberghe > <sven(a)stfx.eu > <mailto:sven@stfx.eu>> wrote: > > > > On 18 May 2015, at 15:47, Manfred KrÃ¶hnert > <mkroehnert42(a)googlemail.com > <mailto:mkroehnert42@googlemail.com>> wrote: > > > > Hi, > > apparently I am missing something else. > > > > I can find devices when connected to a 'regular' LAN. > > > > However, I have a camera that creates a Wifi accesspoint and > makes itself discoverable via SSDP. > > Once I connect to this accesspoint my computer gets a valid IP > address assigned and the NodeJS code is able to discover the device. > > Unfortunately, the Pharo snippet I posted before does not give me > any results and hangs in Socket>>waitForDataIfClosed: . > > > > Any further ideas? > > Are you sure you restarted the image and your code after switching > networks ? > > > I did not check this before. > But I just downloaded a fresh 40613 image with PharoLauncher and started > it after connecting to the camera accesspoint. > The code snippet freezes there as well. > > Manfred

May 18, 2015

Re: [Pharo-users] [Moose-dev] [SURVEY] Pillar input/output files.

by Alexandre Bergel

Hi Cyril, It does not look that different. Something I may recommend, is that Pillar should be effective at writing other things than a book. So, the chapter decomposition should not be forced. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > On May 4, 2015, at 7:38 AM, Cyril Ferlicot <cyril.ferlicot(a)gmail.com> wrote: > > Hi, > I'm currently working on the way we manage the input files and the output files. > The way we manage the files now makes hard some improvement of Pillar. > That's why with Damien we though about makes some changes. The changes > are big so I wanted to talk about that with you. > We propose to have always 1 file with all the work inside. That can > use the inputFile tag. For example: > > "${inputFile:Chapter1.pillar}$ > > ${inputFile:Chapter2.pillar}$ > > ${inputFile:Chapter3.pillar}$ > > ${inputFile:Chapter4.pillar}$" > > And the option "separateOutputFiles" will now create 1 file each time > we have a new Chapter. (!Level 1 header). > That will make simpler the way to number everything and to create > anchor because those 2 doesn't work well with the "separateOutputFile" > option. > > What do you thing? That would be good with you? > > -- > Cheers > Cyril Ferlicot > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev

May 18, 2015

Re: [Pharo-users] [Pharo-dev] [Moose-dev] [SURVEY] Pillar input/output files.

by Cyril Ferlicot

Hi, I think we'll be able to avoid what i've expose on the first message. I changed the way Pillar parsed the files so it's not easier to create a global numerator or inter file links. When i'll have something that work i'll do a new configuration a post a message on the ML. On 18 May 2015 at 22:53, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Hi Cyril, > > It does not look that different. Something I may recommend, is that Pillar > should be effective at writing other things than a book. So, the chapter > decomposition should not be forced. > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > On May 4, 2015, at 7:38 AM, Cyril Ferlicot <cyril.ferlicot(a)gmail.com> wrote: > > Hi, > I'm currently working on the way we manage the input files and the output > files. > The way we manage the files now makes hard some improvement of Pillar. > That's why with Damien we though about makes some changes. The changes > are big so I wanted to talk about that with you. > We propose to have always 1 file with all the work inside. That can > use the inputFile tag. For example: > > "${inputFile:Chapter1.pillar}$ > > ${inputFile:Chapter2.pillar}$ > > ${inputFile:Chapter3.pillar}$ > > ${inputFile:Chapter4.pillar}$" > > And the option "separateOutputFiles" will now create 1 file each time > we have a new Chapter. (!Level 1 header). > That will make simpler the way to number everything and to create > anchor because those 2 doesn't work well with the "separateOutputFile" > option. > > What do you thing? That would be good with you? > > -- > Cheers > Cyril Ferlicot > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- Cheers Cyril Ferlicot

May 18, 2015

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

by Ben Coman

On Mon, May 18, 2015 at 7:06 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > 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. This sparked my interest to read RFC3986 ( https://tools.ietf.org/html/rfc3986#section-5.2.4) which says: A relative reference that begins with a single slash character is termed an absolute-path reference. A relative reference that does not begin with a slash character is termed a relative-path reference." The path segments "." and "..", also known as dot-segments, are defined for relative reference within the path name hierarchy. They are intended for use at the beginning of a relative-path reference to indicate relative position within the hierarchical tree of names." Within a representation with a well defined Base URI of "http://a/b/c/d;p?q" a relative reference is transformed to its Target URI as follows. "g:h" = "g:h" "g" = "http://a/b/c/g" "./g" = "http://a/b/c/g" "../g" = "http://a/b/g" "/g" = "http://a/g" So slightly as an aside, this makes me wonder if we should consider that when the Image is a opened as a file, its Base URI can be considered to be 'file:///b/c/Pharo.image' such that its reasonable to have the following relative references transformed as follows: 'g:h' asUrl asString "--> 'g:h' 'g' asUrl asString "--> 'file:///b/c/g' './g' asUrl asString "--> 'file:///b/c/g' '../g' asUrl asString "--> 'file:///b/g' '/g' asUrl asString "--> 'file:///g' Effectively, the default scheme is #file rather than nil, as it is currently. RFC3986 5.2.2. "Transform References" shows a non-strict case where it seems that following intuitive example is valid 'file:///./g' asUrl asString "--> file:///b/c/g' " per this line... T.path = merge(Base.path, R.path); RFC3986 5.1.2. "Base URI from the Encapsulating Entity" indicates we could consider the Base URI for the sqlite3 scheme to derive from the Image's 'file:///b/c/Pharo.image' URI to be... 'sqlite3:///b/c/Pharo.image' such that per 5.2.2. the following would be valid... 'sqllite3:///./g' asUrl asString "--> sqllite3:///b/c/g' " All that is from a patchy skim of RFC3986, so maybe I got it wrong, but maybe its a view worth considering. > 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'" > > > An intuitive semantic would be... ''sqlite3:///./c/myDirectory/myfile.db' asUrl pathPrintString "--> /my/pharoImagePath/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. > Would memory have a hierarchical structure? i.e. if I wanted to run two sqllite3 instances in memory? > > '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 > > > > > > > > > > Looking through Zinc I notice that the schemes are symbols. Any plans to make these classes? To maybe(?) make it easier to extend to other schemes ( http://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml) ? Or do you consider that outside the scope of Zinc ? cheers -ben

May 18, 2015