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

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

by Laurent

Le mar. 19 mai 2015 Ã 5:45, Avdi Grimm <avdi(a)avdi.org> a Ã©crit : > > On Mon, May 18, 2015 at 11:06 PM, Ben Coman <btc(a)openinworld.com> > wrote: >> 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. > > Interesting! How does one add more than one window to the group? Is > there more info on this somewhere? This work comes from TilingWindowManager and has been reified into GroupWindowMorph in Pharo3. With TWM comes TWMDockingWindowMorph with opens a docking panel where you can put windows. See https://vimeo.com/26346973 and open it with: TWMDockingWindowMorph new openInWorld Laurent > > > -- > Avdi Grimm > http://avdi.org >

May 19, 2015

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

by Cyril Ferlicot

Oh, thank you for this one ! Maybe we could add a little paragraph about it on UPBE! That's really usefull On 19 May 2015 at 05:06, Ben Coman <btc(a)openinworld.com> wrote: > > 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 -- Cheers Cyril Ferlicot

May 19, 2015

Re: [Pharo-users] Smalltalkhub password reset

by mtk

Hi Steph, would it be better to stay with SqueakSource3? Kind regards Marcus -- View this message in context: http://forum.world.st/Smalltalkhub-password-reset-tp4827089p4827230.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

May 19, 2015

Re: [Pharo-users] Issue with UDP Sockets

by Udo Schneider

True - having Wireshark is always a good idea. Just a warning in the multicast context though: The fact that Wireshark sees multicast datagrams (when recieving) does only imply that your NIC is in promiscuous mode or that /a/ process on the node did subscribe to the multicast group. It does not necessarily mean that /your/ process will get the datagram via it's socket. Debugging multicast is a little bit tricky. With unicast or broadcast datagrams (doesn't matter if Ethernet or IP) it's quite easy: The NIC accepts every Broadcast L2 datagram and forwards it to the IP stack which processes every L3 broadcast datagram. For unicast the NIC only accepts datagrams sent to it's MAC address and the IP stack only processes them when sent to (one if) it's IP addresses. With multicast being "something in between" you have to convince the NIC (IP Multicast addresses map to specific Ethernet MACs) and the IP Stack to process the datagram although it's neither directly sent to their MAC/IP nor a broadcast. CU, Udo On 19/05/15 04:17, Ben Coman wrote: > 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 > <mailto:udo.schneider@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 <http://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> > <mailto:sven@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> > > <mailto:mkroehnert42@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] Smalltalkhub password reset

by stepharo

Le 18/5/15 13:36, mtk a Ã©crit : > Hi, > > I lost my password for smalltalkhub. I read some older messages in the > interwebs that one has to directly ask Nicolas Petton for resetting the > password, but this didn't work. Is there another way? Maybe a password reset > mechanism would be fine... :-) You mean in 2013 that "modern" web app do not have that by default. Sad :( > > Best > > Marcus > > > > -- > View this message in context: http://forum.world.st/Smalltalkhub-password-reset-tp4827089.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

May 19, 2015

Re: [Pharo-users] Creating a Class in a Temporary Environment

by Marcus Denker

> On 12 May 2015, at 14:57, Camille <camille.teruel(a)gmail.com> wrote: > > Hi Sean, > > You can use AnonymousClassInstaller instead of PharoClassInstaller. Hmmmâ¦ I donât like that. It is for anonymous classes. We should fix the class builder itselfâ¦ and check that Opal can use environments, too. It is already on my TODO... > We should improve it because it has limitations: the environment is not used and you wonât be able to change the slots or the superclass after creation. > > AnonymousClassInstaller make: [ :builder | > builder > superclass: Object; > name: #AClassForTesting ]. > > Camille > > >> On 12 May 2015, at 12:45, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >> >> I used to have >> >> creatingAClassInATemporaryNamespace >> >> | testingEnvironment morph | >> testingEnvironment := SystemDictionary new. >> >> ClassBuilder new >> name: #AClassForTesting >> inEnvironment: testingEnvironment >> subclassOf: Object >> type: Object typeOfClass >> instanceVariableNames: '' >> classVariableNames: '' >> poolDictionaries: '' >> category: 'TemporaryTesting'. >> >> How do I do this with Slots? >> >> I tried: >> >> creatingAClassInATemporaryNamespace >> >> | testingEnvironment morph | >> testingEnvironment := SystemDictionary new. >> >> PharoClassInstaller make: [ :builder | >> builder >> superclass: Object; >> name: #AClassForTesting; >> environment: testingEnvironment; >> category: 'TemporaryTesting' ]. >> >> but got "key #SystemOrganization not found in SystemDictionaryâ. >> >> ----- >> Cheers, >> Sean >> -- >> View this message in context: http://forum.world.st/Creating-a-Class-in-a-Temporary-Environment-tp4825963… >> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >> > >

May 19, 2015

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

by Avdi Grimm

I gotta say, I was *very* happy to see the Spotter in Pharo 4. This approach, the grand unified auto-completing fuzzy find-by-anything box, is one of the greatest programming UX advances in recent memory. There's a reason there's now a version of it in every editor or IDE I know of. That's not to say there's no place for a Browser approach. But what's interesting to me is that I think the Spotter represents the 80% case. 80% of the time, we have a good idea of what we're looking for and we just want to get to it quickly. Browsers are more helpful for the 20% of the time when we're new to the code and we're exploring. On Tue, May 19, 2015 at 12:42 AM Joachim Tuchel <jtuchel(a)objektfabrik.de> wrote: > We're in agreement here. It is nog about the panes per se. It's about the > fact that once you reached an artefact to read or edit, there is no need > for the navigation to cover a lot of space on screen. Multiplied by the > number of open browsers. Until you commence your journey through your code. > > Then there is the problem of navigation being much more than just packages > and class hierarchies. There is the question of why and how did I get here? > That area is uncovered in most IDEs - not only Smalltalk. > > Another problem area is the longevity of a need to have some artefact > open. How often do we close 10, 15, 20 inspectors at once, because we don't > need them any more? When we look for the place where something started, we > travel from implementor to implementor, via some senders until we finally > get to where we can answer our question af hand. Sometimes we reach a dead > end, need to go back a step or two and try another branch. But does it > really mean we need each stop of the path as an open window? Forever? Or > are there better ways to navigate? > > I am getting so off-topic it hurts, but these questions need an answer, > and the Smalltalk community should be one that can solve them much more > easily than others because our language lets us concentrate on the problem. > > Joachim

May 19, 2015

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

by Joachim Tuchel

We're in agreement here. It is nog about the panes per se. It's about the fact that once you reached an artefact to read or edit, there is no need for the navigation to cover a lot of space on screen. Multiplied by the number of open browsers. Until you commence your journey through your code. Then there is the problem of navigation being much more than just packages and class hierarchies. There is the question of why and how did I get here? That area is uncovered in most IDEs - not only Smalltalk. Another problem area is the longevity of a need to have some artefact open. How often do we close 10, 15, 20 inspectors at once, because we don't need them any more? When we look for the place where something started, we travel from implementor to implementor, via some senders until we finally get to where we can answer our question af hand. Sometimes we reach a dead end, need to go back a step or two and try another branch. But does it really mean we need each stop of the path as an open window? Forever? Or are there better ways to navigate? I am getting so off-topic it hurts, but these questions need an answer, and the Smalltalk community should be one that can solve them much more easily than others because our language lets us concentrate on the problem. Joachim

May 19, 2015

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

by Avdi Grimm

On Mon, May 18, 2015 at 11:41 PM, jtuchel(a)objektfabrik.de < jtuchel(a)objektfabrik.de> wrote: > 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. I was just thinking about this the other day. I don't think there's anything fundamentally wrong with the four-pane approach (although there are other perfectly valid approaches as well). But once you've found what you're looking for, the panes take up *way* more screen space than is necessary just to remind you where you are. It would be neat to see a version where the panes fold away down to a "location" bar when you're not actively navigating to a new method. -- Avdi Grimm http://avdi.org

May 19, 2015

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

by Avdi Grimm

On Mon, May 18, 2015 at 11:06 PM, Ben Coman <btc(a)openinworld.com> wrote: > 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. Interesting! How does one add more than one window to the group? Is there more info on this somewhere? -- Avdi Grimm http://avdi.org

May 19, 2015