- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] it's too quiet ... please ignore (except for stef:)

by Ron Teitelbaum

Hi Dale! Ron Teitelbaum -----Original Message----- From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Dale Henrichs Sent: Thursday, December 29, 2016 1:10 PM To: Pharo Development List; stepharong Subject: Re: [Pharo-dev] it's too quiet ... please ignore (except for stef:) The list server is up so it's just quiet:) On 12/29/16 10:04 AM, Dale Henrichs wrote: > No messages on list since yesterday morning? > > Dale >

Dec. 29, 2016

Re: [Pharo-dev] it's too quiet ... please ignore (except for stef:)

by Dale Henrichs

I always got in trouble on Christmas ... getting up too early:) On 12/29/16 11:00 AM, Dimitris Chloupis wrote: > Shhhh .... we are waiting for Santa ;) > On Thu, 29 Dec 2016 at 20:10, Dale Henrichs > <dale.henrichs(a)gemtalksystems.com > <mailto:dale.henrichs@gemtalksystems.com>> wrote: > > The list server is up so it's just quiet:) > > > On 12/29/16 10:04 AM, Dale Henrichs wrote: > > No messages on list since yesterday morning? > > > > Dale > > > >

Dec. 29, 2016

Re: [Pharo-dev] it's too quiet ... please ignore (except for stef:)

by Dimitris Chloupis

Shhhh .... we are waiting for Santa ;) On Thu, 29 Dec 2016 at 20:10, Dale Henrichs < dale.henrichs(a)gemtalksystems.com> wrote: > The list server is up so it's just quiet:) > > > On 12/29/16 10:04 AM, Dale Henrichs wrote: > > No messages on list since yesterday morning? > > > > Dale > > > > >

Dec. 29, 2016

Re: [Pharo-dev] it's too quiet ... please ignore (except for stef:)

by Dale Henrichs

The list server is up so it's just quiet:) On 12/29/16 10:04 AM, Dale Henrichs wrote: > No messages on list since yesterday morning? > > Dale >

Dec. 29, 2016

it's too quiet ... please ignore (except for stef:)

by Dale Henrichs

No messages on list since yesterday morning? Dale

Dec. 29, 2016

Re: [Pharo-dev] [Ann] Calypso system browser

by Denis Kudriashov

2016-12-28 18:12 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > > I like this initiative, especially for the local browser and the > remote browser using the same code base. > * overall minimizing code > * using/testing the same mechanisms > * facilitate seamless experience between local and remote usage And thank's for feedback. I saw you created issues. It is good

Dec. 28, 2016

Re: [Pharo-dev] [Ann] Calypso system browser

by Denis Kudriashov

2016-12-28 18:12 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > * multiple code pane tabs - cool > * multi-selection is cool (but I need to trial how it works out in > practice) > * automatic selection of items similar to last selection - I've been > meaning to ask this for Nautilus for a while. > * pinning modified pane code panes is a nice approach. It would be > nice to pin any pane. > * packages pane - it would be nice for the test-result-icon to appear > on left like the other panes. The folder icon would seem reasonable > place to substitute. > > Nice feature to show variables in the protocol pane and references in > the method list pane. But it says "Class variables" while these are > "Instance Variables" > Because Class variables are also accessible from instance side and you want to see what methods are used it. But I agree it should not be here by default. Actually it will be not here if Object will not define any class variable. But Object has DependantFields. Browser probably should ignore it. Now structure of variables view is the same as when you click on Variables button in Nautilus. So you think existence of "Class variables" is also confusing because it looks like parent group for instance variables? > > Now I wonder if we can do without the Methods/Vars buttons by having > the following top level tree items. Also as a newbie before developing > the instinct to *know* which instance/class-side I was on, I got burnt > a few times following tutorials accidentally putting methods on the > wrong side. It would be interesting to try deprecating the > Inst-Side/Class-Side buttons, and have something like the following > items... > + instance-side methods > - accessing > - initialization > - extensions > - GT-InspectorExtensions > + class-side methods > - instance creation > - extensions > + variables > - instance variables > - class variables > - class instance variables > > It could be good or not. Problem with this approach is same as why we use 4-column panes instead of single tree menu for everything like other IDE does. We don't want to scroll to achieve some group element. Imaging that you browse some morph subclass which have a lot of protocols. You are in some middle protocol and not see parent expanded group in list. And now you want to look at class side or variables. Tree view will force you to scroll instead of simple press on switch button like it is now. > The "inherited methods" tree-item might be better as a pull down menu > at the bottom of the pane, level with "Filter..." since visually it is > confusing seeming that protocols like "accessing" are a sub-item of > "inherited methods". > But it is not expanded and indentation of both items are same. Also you can select "inherited methods" as any other group and see all inherited methods together without using visibility checkbox.

Dec. 28, 2016

Re: [Pharo-dev] [Ann] Calypso system browser

by Ben Coman

On Wed, Dec 28, 2016 at 12:12 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Hi > > I am glad announce first initial version of new system browser called > Calypso. It is implemented from scratch with idea to build model suitable > for remote scenario. But as result it leads to more important goal: provide > clean implementation of browser which people could understand and evolve. I like this initiative, especially for the local browser and the remote browser using the same code base. * overall minimizing code * using/testing the same mechanisms * facilitate seamless experience between local and remote usage > > Calypso supports most features from Nautilus but also miss many of them. And > there are many not nicely looking parts of UI which require more work. > But in same time Calypso provides many new cool features with clean > implementation underhood. I put many things from other smalltalks and old > browsers which I always miss. > > I release Calypso in the state where I finish most design decisions which I > think important for project evolution. > Of course there are a lot of things to do and improve. But browser is fully > working. And now it is important to community to participate in project and > make browser great again :). We need escape from Nautilus pasta world. > Please report any ideas/bugs on github page > https://github.com/dionisiydk/Calypso/issues. I already fill it with my > wishes. > > Next step I will work on documentation/class comments and I will publish > couple of posts about Calypso internals. > > Read more details on my blog. It includes pictures, videos and loading > script. * multiple code pane tabs - cool * multi-selection is cool (but I need to trial how it works out in practice) * automatic selection of items similar to last selection - I've been meaning to ask this for Nautilus for a while. * pinning modified pane code panes is a nice approach. It would be nice to pin any pane. * packages pane - it would be nice for the test-result-icon to appear on left like the other panes. The folder icon would seem reasonable place to substitute. Nice feature to show variables in the protocol pane and references in the method list pane. But it says "Class variables" while these are "Instance Variables" Now I wonder if we can do without the Methods/Vars buttons by having the following top level tree items. Also as a newbie before developing the instinct to *know* which instance/class-side I was on, I got burnt a few times following tutorials accidentally putting methods on the wrong side. It would be interesting to try deprecating the Inst-Side/Class-Side buttons, and have something like the following items... + instance-side methods - accessing - initialization - extensions - GT-InspectorExtensions + class-side methods - instance creation - extensions + variables - instance variables - class variables - class instance variables The "inherited methods" tree-item might be better as a pull down menu at the bottom of the pane, level with "Filter..." since visually it is confusing seeming that protocols like "accessing" are a sub-item of "inherited methods". cheers -ben

Dec. 28, 2016

Re: [Pharo-dev] IDNA / punycode for Zinc?

by Sven Van Caekenberghe

Hi Yoshihiko, Thank you, I'll put the integration of your code with Zinc's URL on my todo list. Sven > On 27 Dec 2016, at 16:32, Yoshihiko Kubota <y.kubota(a)mail.dendai.ac.jp> wrote: > > Hi > > I wrote PunycodeConverter. > I received a mail from Sven. But I overlooked. > I already sent a mail to Seven. > Please use my code. But it need to kaizen. > > http://smalltalkhub.com/#!/~dTriangle/Punycode > On 2016å¹´11æ24æ¥ at 4:14:16, phil(a)highoctane.be (phil(a)highoctane.be) wrote: > >> I am always amazed about the cool things I can learn from this list. >> >> Phil >> >> On Wed, Nov 23, 2016 at 4:59 PM, Max Leske <maxleske(a)gmail.com> wrote: >> :) Nice. >> >> >> >> > On 23 Nov 2016, at 16:51, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> > >> > https://pharo.fogbugz.com/f/cases/19383/IDNA-punycode-for-Zinc >> > >> > After loading >> > >> > Name: Punycode-dTriangle.8 >> > Author: dTriangle >> > Time: 26 August 2013, 10:19:11.728 am >> > UUID: 6493a3ee-43bb-44f0-86a8-5aa47a9b42ff >> > Ancestors: Punycode-dTriangle.7 >> > >> > I can do the following >> > >> > 'http://Ã¼ni.ch' asUrl. >> > >> > "http://xn--ni-wka.ch/" >> > >> > 'http://Ã¼ni.ch' asUrl retrieveContents includesSubstring: 'Ãni'. >> > >> > "true" >> > >> > Done ;-) >> > >> > Thank you, https://twitter.com/osashimitabenai, well done ! >> > >> > Sven >> > >> >> On 23 Nov 2016, at 15:43, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> >> >> >> >>> On 23 Nov 2016, at 15:36, Max Leske <maxleske(a)gmail.com> wrote: >> >>> >> >>> Great! >> >>> >> >>> Thereâs a punycode implementation on smalltalkhub (http://smalltalkhub.com/#!/~dTriangle/Punycode) but it needs some polishing. >> >> >> >> Wow, that looks good, it even has ZnUrl integration, so we're done ;-) >> >> >> >> There are no tests though. >> >> >> >> How come we never heard of this ? >> >> >> >> Last commit was in 2013, hopefully the author is still around. >> >> >> >>> Should I open an issue on FogBugz so we donât forget? >> >> >> >> Yes, OK. >> >> >> >>> Max >> >>> >> >>>> On 23 Nov 2016, at 15:00, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >>>> >> >>>> Max, >> >>>> >> >>>>> On 23 Nov 2016, at 14:34, Max Leske <maxleske(a)gmail.com> wrote: >> >>>>> >> >>>>> Hi (Sven), >> >>>>> >> >>>>> Zinc canât currently handle unicode domain names (e.g. http://Ã¼ni.ch) Are there any plans to implement punycode / IDNA conversion for Zinc? Or is there an explicit reason not to support it? I see that # parseHostPort: expects the host portion to be percent escaped, what is the use case for this? I have never seen a percent escaped host portion. Usually the host portion is either pure ASCII, unicode or punycode (in my experience at least). >> >>>>> >> >>>>> Just curious, as I just added IDNA conversion to one of our applications (I just let python perform the conversion: https://docs.python.org/2/library/codecs.html#module-encodings.idna) >> >>>>> >> >>>>> Cheers, >> >>>>> Max >> >>>> >> >>>> Yes, that would be nice to have. >> >>>> >> >>>> Just for future reference, we are talking about the following (IDN(A)): >> >>>> >> >>>> https://en.wikipedia.org/wiki/Internationalized_domain_name >> >>>> https://en.wikipedia.org/wiki/Punycode >> >>>> https://tools.ietf.org/html/rfc3490 >> >>>> https://www.charset.org/punycode >> >>>> >> >>>> Normal DNS hostnames are ASCII only (or used to be like that anyway), that is why it is (currently) implemented like that. >> >>>> >> >>>> Sven >> >>>> >> >>>> >> >>> >> >> >> > >> >

Dec. 28, 2016

Re: [Pharo-dev] [Ann] Calypso system browser

by Denis Kudriashov

2016-12-28 15:21 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>: > Nice work! > > I particularly like the focus on low traffic between the model and the UI. > I think there is a good deal of things to learn from the experience of > building remote tools. > Calypso supposed to work good in remote scenario. It was always main design goal. So soon we will have remote browser based on Calypso

Dec. 28, 2016