- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] context menu keyboard key

by Nicolai Hess

2015-12-06 12:37 GMT+01:00 Peter Uhnak <i.uhnak(a)gmail.com>: > Hi, > > is there a way to open context menu without using mouse/right click? > > Keyboards generally have a special key for this, but Pharo doesn't seem > to even recognize the keypress. > some time ago, esc-key was used for that. > > To anyone familiar with this, can this be fixed in image? Or digging > into VM is needed? > don't know when it was gone, but it should be possible to fix this in-image. > > Thanks, > -- > Peter > >

Dec. 6, 2015

context menu keyboard key

by Peter Uhnak

Hi, is there a way to open context menu without using mouse/right click? Keyboards generally have a special key for this, but Pharo doesn't seem to even recognize the keypress. To anyone familiar with this, can this be fixed in image? Or digging into VM is needed? Thanks, -- Peter

Dec. 6, 2015

Re: [Pharo-dev] issue 12231 DisplayScreen hostWindowTitle: not working on Linux (ubuntu)

by kmo

Very interesting idea, bug bankruptcy. We certainly suffer from it where I work. As for the bug, I'd just like to thank Nicolai for taking the time to investigate it and work out a fix. -- View this message in context: http://forum.world.st/issue-12231-DisplayScreen-hostWindowTitle-not-working… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Dec. 6, 2015

Re: [Pharo-dev] issue 12231 DisplayScreen hostWindowTitle: not working on Linux (ubuntu)

by stepharo

What everybody should understand is that context switch is difficult and cost a lot of energy. So making clear what is the next step for an action is really important. It helps people to follow. Stef Le 6/12/15 06:05, Ben Coman a Ã©crit : > On Sat, Dec 5, 2015 at 7:40 PM, kmo <voxkmp(a)gmail.com> wrote: >> I think it was me who reported the bug. If it's going to be closed without >> being fixed that just means I wasted my time. Not a good message to send >> out. > You are right, its not ideal. On the flip side, from the issue > history it appears that Nicolai took the time to dig into the problem, > understand it and provide a fix. So your report was not ignored. > Closing the bug unfixed would also waste that effort of Nicolai's, but > since he is the one who donated his time on your behalf, I believe he > is entitled to make that call to moderate "bug bankruptcy" per [1]. > Thats how open source works. > > Now it would be *real*nice* if we had a bug bounty system where you > could prioritize bugs important to you, but in the meantime, if the > issue had no progress for two years, its an important question to ask > how likely is it to progress further on its own. We can't do > everything and a bug backlog consumes resources to manage. So while > Fogbugz is good as a tracker and a historian, its useful to socialise > issues on the mail list from time to time to help prioritise them. > Anyway, it seem Nicolai's mail had the desired effect of bumping it on > an action list. > > [1] http://www.joelonsoftware.com/items/2012/07/09.html > > cheers -ben > >

Dec. 6, 2015

Re: [Pharo-dev] issue 12231 DisplayScreen hostWindowTitle: not working on Linux (ubuntu)

by Ben Coman

On Sat, Dec 5, 2015 at 7:40 PM, kmo <voxkmp(a)gmail.com> wrote: > I think it was me who reported the bug. If it's going to be closed without > being fixed that just means I wasted my time. Not a good message to send > out. You are right, its not ideal. On the flip side, from the issue history it appears that Nicolai took the time to dig into the problem, understand it and provide a fix. So your report was not ignored. Closing the bug unfixed would also waste that effort of Nicolai's, but since he is the one who donated his time on your behalf, I believe he is entitled to make that call to moderate "bug bankruptcy" per [1]. Thats how open source works. Now it would be *real*nice* if we had a bug bounty system where you could prioritize bugs important to you, but in the meantime, if the issue had no progress for two years, its an important question to ask how likely is it to progress further on its own. We can't do everything and a bug backlog consumes resources to manage. So while Fogbugz is good as a tracker and a historian, its useful to socialise issues on the mail list from time to time to help prioritise them. Anyway, it seem Nicolai's mail had the desired effect of bumping it on an action list. [1] http://www.joelonsoftware.com/items/2012/07/09.html cheers -ben

Dec. 6, 2015

Re: [Pharo-dev] Java Future

by Ben Coman

On Fri, Dec 4, 2015 at 3:51 PM, EuanM <euanmee(a)gmail.com> wrote: > Hi Steph, > > As a newcomer, here is my experience with my first bug-fix: > > I wrote the fix in about 5 minutes. What was the issue number? cheers -ben > It then took several weeks to get the big-fix accepted because of > issues with the repository and, separately, with bitrot in the list of > maintainers. > > On 30 November 2015 at 16:52, stepharo <stepharo(a)free.fr> wrote: >> True help closing bug >> Build a great library >> Buidl a cool software >> >> Stef >> >> Le 30/11/15 04:44, EuanM a Ã©crit : >> >>> We also need to concentrate on building our community. >>> >>> We build a better platform faster if we have more people. >>> >>> We build a more valuable platform if we have a wider range of valuable >>> use cases to target. >>> >>> Unless and until we hit a critical mass of people joining our >>> community, we *need* to spend some of our focus on community-building. >>> >>> Part of great is being able to build things to sufficient completeness >>> *and* keep them in working order over the long haul. This is easier >>> with more contributors. >>> >>> On 27 November 2015 at 21:27, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>>> >>>> Hello everyone, >>>> >>>> Please stop this thread on this mailing list. We need to focus on >>>> building a great platform. >>>> >>>> Cheers, >>>> Doru >>>> >>>> >>>>> On Nov 27, 2015, at 10:05 PM, EuanM <euanmee(a)gmail.com> wrote: >>>>> >>>>> First of all - is this true? Where can we read about it? >>>>> >>>>> I cannot find anything about this at >>>>> https://www.oracle.com/search/press >>>>> >>>>> ======================================= >>>>> >>>>> If Oracle did make this statement, then what people have said so far >>>>> is true. BUT... >>>>> >>>>> Java got about 40% of its initial momentum from IBM dumping VisualAge >>>>> and putting all their resources into Java. >>>>> >>>>> Oracle are targetting this move at IBM more than anyone else. >>>>> >>>>> IBM will start to think about how to migrate from Java - as Oracle are >>>>> telling them they will have to. (It's OUR bat and its OUR ball, and >>>>> no-one else can play with it. Not even the Java Community). And >>>>> IBM's coders do not pay for Java, Eclipse users do not pay for Java. I >>>>> expect the licence-fee income for JREs is small. >>>>> >>>>> Oracle are doing one of two things - announcing that Java is for sale >>>>> to device providers - phones (Google is the obvious buyer) or the >>>>> impending Internet of Things (which was what Java was designed for >>>>> originally) or announcing that no-one making an internet of things >>>>> offering should consider Java. >>>>> >>>>> Yes, things live on and on in a kind of zombie state. So yes, things >>>>> live on as long as their ecosystem does. And they gently wither and >>>>> their ecosystem withers is a long slow drawn out spiral. Which is why >>>>> we still have Cobol. >>>>> >>>>> People and organisations tend to move from one technology to another >>>>> in an incremental fashion. Swapping a little bit here, and a little >>>>> bit there. >>>>> >>>>> The new target platforms are ones which >>>>> 1) look like they have longevity, and >>>>> 2) have a migration pathway that provides incremental steps. >>>>> >>>>> Offering a compelling advantage is good - but only if the steps 1) >>>>> and 2) are catered to. >>>>> >>>>> IBM VisualAge Smalltalk is still robust, commercially available >>>>> software, and VisualStudio and Gemstone continue to represent >>>>> Smalltalk out to the big world of corporate development. >>>>> >>>>> So that's a start. >>>>> >>>>> Say only 5% of the Java world moves away from Java each year, as a >>>>> result of this announcement. >>>>> >>>>> We *should* wish to take advantage of this announcement. >>>>> >>>>> After all, think what difference having even 0.01% of the world's Java >>>>> coders moving to Smalltalk would make. How could we help that >>>>> happen? >>>>> >>>>> Think what it would be like to have thought-leaders like Kent Beck and >>>>> Ward Cunningham back in the Smalltalk fold. How could we help that >>>>> happen? >>>>> >>>>> Think what it would be like to get back all the universities who moved >>>>> from teaching OO concepts using Smalltalk into teaching them via Java. >>>>> We now know almost all the ones using Smalltalk as a teaching language >>>>> by name. Does anyone know even how many universities teach OO via >>>>> Java? What would it be like if 5% of those universities moved to >>>>> Smalltalk each year. How could we help that happen? >>>>> >>>>> Next - do we have any big brained thinkers who can see specific ways >>>>> we can improve interoperation between Java facilities and libraries >>>>> and the Smalltalks? For the next 12 months, we should work on Java >>>>> integration, rather than C++ integration. We should identify the >>>>> three best things for us to do in this regard, and make them polished >>>>> and compelling. Who is in a position to help that happen? >>>>> >>>>> The final way we can take advantage help the maximum number of people >>>>> find their way to us is to present a united community front to the >>>>> outside world. In the same way I am both a European and a Scot, we >>>>> need to be Smalltalkers *and*members of our individual >>>>> Smalltalk-platform communities. >>>>> >>>>> How can we help make that happen? >>>>> >>>>> This is not a silver bullet. It's going to cause a long-term trend in >>>>> events, not a sudden abrupt change. But it will have a real, if >>>>> gradual effect. (assuming that >>>>> >>>>> Equally, it is not something we should ignore. It is something we >>>>> should make use of. We need to put effort into raising our profile >>>>> over the next 6 months. >>>>> >>>>> On 25 November 2015 at 19:51, Casimiro - GMAIL >>>>> <casimiro.barreto(a)gmail.com> wrote: >>>>>> >>>>>> Em 25-11-2015 17:21, Nicolas Anquetil escreveu: >>>>>> >>>>>> >>>>>> >>>>>> On 25/11/2015 19:55, Jimmie Houchin wrote: >>>>>> >>>>>> Much truth in what you say. However, what Oracle choose to invest its >>>>>> money, >>>>>> time, personnel resource into Java does affect its present and future. >>>>>> It >>>>>> has a great affect. But it isn't the whole story. Java has enough >>>>>> momentum >>>>>> in what already exists in the language and vm and what has been release >>>>>> under its license, for businesses to keep going for some time with only >>>>>> what >>>>>> currently exists. >>>>>> >>>>>> Cobol is still alive (and well) after > 50 years. >>>>>> You can expect Java programmers to find jobs for many years yet to come >>>>>> :-) >>>>>> >>>>>> nicolas >>>>>> >>>>>> -- >>>>>> Nicolas Anquetil >>>>>> RMod team -- Inria Lille >>>>>> >>>>>> 1st: Java is extremely profitable. Each android phone, each android TV, >>>>>> each >>>>>> android embedded system pays copyrights to Oracle. >>>>>> 2nd: Much of current cloud infrastructure depends on java. >>>>>> 3rd: Java is already obsolete, like Frotran, Cobol, C, C++. It will >>>>>> continue >>>>>> to be used by same reasons these languages are used. >>>>>> >>>>>> IMHO, discussing java is not profitable. Better to discuss things to be >>>>>> than >>>>>> talk about things that already happened. >>>>>> >>>>>> casimiro >>>>>> >>>>>> -- >>>>>> The information contained in this message is confidential and intended >>>>>> to >>>>>> the recipients specified in the headers. If you received this message >>>>>> by >>>>>> error, notify the sender immediately. The unauthorized use, disclosure, >>>>>> copy >>>>>> or alteration of this message are strictly forbidden and subjected to >>>>>> civil >>>>>> and criminal sanctions. >>>>>> >>>>>> == >>>>>> >>>>>> This email may be signed using PGP key ID: 0x4134A417 >>>> >>>> -- >>>> www.tudorgirba.com >>>> >>>> "Reasonable is what we are accustomed with." >>>> >>>> >>> >> >> >

Dec. 6, 2015

Re: [Pharo-dev] [squeak-dev] Crypto plugins for ubuntu 32-bits

by Robert Withers

10 years is long enough. :) How can I help? On 12/05/2015 05:28 PM, David T. Lewis wrote: > On Fri, Dec 04, 2015 at 09:57:02PM -0500, Robert Withers wrote: >> I loaded the CryptographyPlugins package, from the Cryptography >> repository into a VMMaker image, and generated the crypto plugins >> externally. Although I have not measured it rigorously, there is a >> noticeable performance improvement with SqueakElib tests. >> >> Untar these Ubuntu 32-bit crypto plugins into /usr/local/lib/squeak/5.0... >> >> https://www.dropbox.com/s/v502zudwsbtr243/CryptoPlugins.ubuntu32.12.4.15.tg… >> >> Let me know any issues. >> >> Regards, >> Robert > Yikes, it seems that we have had this issue open for nearly 10 years now: > > http://bugs.squeak.org/view.php?id=5228 "0005228: Include Cryptographic Primitives in Base VM - DESPlugin" > > Robert, I think you are on the vm-dev list, may I ask some follow up questions there? > > Dave >

Dec. 5, 2015

Re: [Pharo-dev] [squeak-dev] Crypto plugins for ubuntu 32-bits

by David T. Lewis

On Fri, Dec 04, 2015 at 09:57:02PM -0500, Robert Withers wrote: > I loaded the CryptographyPlugins package, from the Cryptography > repository into a VMMaker image, and generated the crypto plugins > externally. Although I have not measured it rigorously, there is a > noticeable performance improvement with SqueakElib tests. > > Untar these Ubuntu 32-bit crypto plugins into /usr/local/lib/squeak/5.0... > > https://www.dropbox.com/s/v502zudwsbtr243/CryptoPlugins.ubuntu32.12.4.15.tg… > > Let me know any issues. > > Regards, > Robert Yikes, it seems that we have had this issue open for nearly 10 years now: http://bugs.squeak.org/view.php?id=5228 "0005228: Include Cryptographic Primitives in Base VM - DESPlugin" Robert, I think you are on the vm-dev list, may I ask some follow up questions there? Dave

Dec. 5, 2015

Re: [Pharo-dev] Help needed: old issues issue tracker entries

by Marcus Denker

> On 30 Nov 2015, at 13:21, marcus.denker(a)inria.fr wrote: > > Hi, > > The issue tracker has 658 open issues. This number is more or less constant. > down to 642! (of course we closed more than that, we are at more than 6 per day closed, but the thing is that new ones get open, too) With >600 issues open, if someone adds a comment in the sense of âthis can be closedâ, can you send me (or the List) a mail? Or put the issue on âfixedâ ? The problem is that with >600 issues, even an issue that is clearly commented as fixed has a very low chance of someone reading the note and closing the entry within any reasonable time frame if we rely on someone stumbling on it by chance... Marcus

Dec. 5, 2015

Re: [Pharo-dev] Differences Compiler vs. OpalCompiler (or parser)

by Eliot Miranda

Hi Andrei, > On Dec 4, 2015, at 11:29 AM, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > > > >> On Sat, Nov 21, 2015 at 3:25 PM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >> >> >> 2015-11-20 22:57 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com>: >>> Hi Nicolai, >>> >>>> On Fri, Nov 20, 2015 at 1:37 PM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >>>> GTDummyExamples class >>>> d: anInteger >>>> <gtExample> >>>> <label: 'Dummy #d:, depends #c:'> >>>> <description: 'should raise an exception as the argument is not anInteger'> >>>> <depends: #c:> >>>> <raises: Literal constant expected -> MessageNotUnderstood> >>>> >>>> ^ 1 + anInteger >>>> >>>> The old Parser complains about the class name "MessageNotUnderstood" used as a pragma >>>> argument without being a string or symbol >>>> >>>> Opal does not complain >>>> >>>> Is Opals behavior intended ? >>> >>> IMO no. The pragma design is that the only valid syntax is of a message pattern with only literal arguments except for the one piece of syntactic sugar where the error temporary name in a primitive call with an error can be given as an identifier, e.g. >>> >>> addressField >>> <primitive: 'primAddressField' module: 'IA32ABI' error: errorCode> >>> ^self primitiveFailed >>> >>> instead of >>> >>> addressField >>> <primitive: 'primAddressField' module: 'IA32ABI' error: 'errorCode'> >>> ^self primitiveFailed >>> >>> >>> The issues are class reference, class redefinition, class removal etc. I guess we could extend the pragma syntax to allow class references but there's a lot of impact. I would prefer if we keep things restricted. There's nothing to stop one using a symbol and mapping it to a class name, e.g. >>> >>> >>> GTDummyExamples class >>> d: anInteger >>> <gtExample> >>> <label: 'Dummy #d:, depends #c:'> >>> <description: 'should raise an exception as the argument is not anInteger'> >>> <depends: #c:> >>> <raises: #MessageNotUnderstood> >>> >>> ^ 1 + anInteger >> >> >> Thanks eliot >> >> Yes, we have this code too, I think, using the global var instead of a symbol happened by accident. >> >> @andrei (and stefan?) can you check the GTDummyExamples methods >> and replace classes with symbol names. >> >> After this is removed I will change the parser to notify about this. > > I updated the pragmas to use symbols. They should be instances of Message, and the Message should hold onto the selector symbol and the argument. There should also be a Pragma class with an api that supports access. I'll gather up the relevant Squeak code (including tests) as a guide. Ok? > > Cheers, > Andrei > >> >> >>> >>> Also, I *hate* this style of pragma. Why not >>> >>> GTDummyExamples class >>> d: anInteger >>> <gtExampleLabel: 'Dummy #d:, depends #c:' >>> description: 'should raise an exception as the argument is not anInteger' >>> depends: #c: >>> raises: #MessageNotUnderstood> >>> >>> ^ 1 + anInteger >>> >>> ? >> >> no idea. >> >> >>> >>> That's how the system is designed to be used. Then the message can be implemented by a builder which performs the selector from a visitor. >>> >>>> From squeaks bugtracker : http://bugs.squeak.org/view.php?id=7770 >>>> >>>> Cascading message sends to super. >>>> >>>> Compiler refuses to compile >>>> super >>>> initialize; >>>> setListProperties >>>> >>>> >>>> It looks like Opal would compile this to >>>> >>>> super initialize. >>>> super setListProperties. >>>> >>>> Intended ? Do we want to keep it? >>>> >>>> NBNativeCodeGen >>>> parseOptions: optionsArray >>>> uses association symbol -> block instead of block -> block >>>> for caseOf arguments. >>>> The old parser does not accept this. >>> >>> >>> >>> -- >>> _,,,^..^,,,_ >>> best, Eliot >

Dec. 5, 2015