- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] #sum:, #detectSum:, #sumNumbers:

by Sven Van Caekenberghe

> On 02 Dec 2015, at 15:21, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > 2015-12-02 15:03 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > On Wed, Dec 2, 2015 at 12:38 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > > >> On Dec 1, 2015, at 5:13 PM, Max Leske <maxleske(a)gmail.com> wrote: > >> > >> @Doru > >> Youâre missing the point: #anyOne *fails* for empty collections. > > > > I am not missing the point at all. I am saying that if you want sum: to be generic, it cannot assume a specific Zero object. > > > > And sum: should be generic because of its name. > > I am missing understanding the other use cases. Can you describe > further the generic nature of #sum & #sum: ? I would have thought by > default they only applied to numbers. > > sum can be applied to anything that supports #+, not only numbers > sum: can be applied to any collection with a block that return some object that supports #+ > > therefore you can not assume 0 (<- a number) is a proper initial value therefore you *need* to work with #anyOne > and as you can not assume a proper initial value, you can not assume a default value for empty collections > -> it should throw an error. If you (the caller of the function) knows what to do with an empty collection you have > to check, or call inject:into: directly, with a proper initial value. I am sorry but I am getting really tired of this, you should read what is being said. I am not suggesting to stop using #anyOne because I like why it is there and what it can do. The change I want is what happens with an empty collection when using the simplest selector, #sum. I do not want to say to some collection of numbers #sumIfEmpty: [0], because summing numbers starting from zero is the most common case and everybody expects that, hence the unary selector fits. I want the less common cases to use the more complicated API, as in some collection of colors #sumIfEmpty: [ Color black ] In my book that is common sense API design. Doing that I do no take anything away, because today you already have to make sure the collection is not empty. The only change would be in the error behaviour. I think that is a reasonable price to pay. Instead of having #anyOne fail, it will say that #+ cannot add 0 to some object, and in a comment we can point to the alternative API. http://izquotes.com/quote/242740 right ? > cheers -ben > > > > >>> On 01 Dec 2015, at 15:31, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > >>> > >>> I don't want to be heretic (or too orthodox), but why not to delegate > >>> this behavior to other class (an iterator maybe?). > >>> > >>> It's too tempting adding these convenience methods to Collection > >>> and/or subclasses, but anything that requires an explicit protocol of > >>> its elements is wrong, IMO. > >>> > >>> something like aCollection arithmetic sum: [...] or.... aCollection > >>> arithmetic avg. > >> > >> > >> Interesting thought! > > > > +100 > > > > Doru > > > >>> > >>> My two cents for this. > >>> > >>> Regards! > >>> > >>> > >>> Esteban A. Maringolo > >>> > >> > >> > > > > -- > > www.tudorgirba.com > > > > "Every thing has its own flow." > > > > > > > > > >

Dec. 2, 2015

Re: [Pharo-dev] #sum:, #detectSum:, #sumNumbers:

by Nicolai Hess

2015-12-02 15:03 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > On Wed, Dec 2, 2015 at 12:38 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > > >> On Dec 1, 2015, at 5:13 PM, Max Leske <maxleske(a)gmail.com> wrote: > >> > >> @Doru > >> Youâre missing the point: #anyOne *fails* for empty collections. > > > > I am not missing the point at all. I am saying that if you want sum: to > be generic, it cannot assume a specific Zero object. > > > > And sum: should be generic because of its name. > > I am missing understanding the other use cases. Can you describe > further the generic nature of #sum & #sum: ? I would have thought by > default they only applied to numbers. > sum can be applied to anything that supports #+, not only numbers sum: can be applied to any collection with a block that return some object that supports #+ therefore you can not assume 0 (<- a number) is a proper initial value therefore you *need* to work with #anyOne and as you can not assume a proper initial value, you can not assume a default value for empty collections -> it should throw an error. If you (the caller of the function) knows what to do with an empty collection you have to check, or call inject:into: directly, with a proper initial value. > > cheers -ben > > > > >>> On 01 Dec 2015, at 15:31, Esteban A. Maringolo <emaringolo(a)gmail.com> > wrote: > >>> > >>> I don't want to be heretic (or too orthodox), but why not to delegate > >>> this behavior to other class (an iterator maybe?). > >>> > >>> It's too tempting adding these convenience methods to Collection > >>> and/or subclasses, but anything that requires an explicit protocol of > >>> its elements is wrong, IMO. > >>> > >>> something like aCollection arithmetic sum: [...] or.... aCollection > >>> arithmetic avg. > >> > >> > >> Interesting thought! > > > > +100 > > > > Doru > > > >>> > >>> My two cents for this. > >>> > >>> Regards! > >>> > >>> > >>> Esteban A. Maringolo > >>> > >> > >> > > > > -- > > www.tudorgirba.com > > > > "Every thing has its own flow." > > > > > > > > > > > >

Dec. 2, 2015

Re: [Pharo-dev] Digest from slack to the mailing list?

by Esteban A. Maringolo

Thanks Gaston I created the Pharo Slack's bot for it, but I'm getting a connection refused error when trying to set up the SlackDigest.com integration. I'll try later. Regards! Esteban A. Maringolo 2015-12-02 11:05 GMT-03:00 GastÃ³n Dall' Oglio <gaston.dalloglio(a)gmail.com>: > Hello. > > Just a thought ... There's a automated tool for do that (I have not tried > yet) > http://slackdigest.com/digest.html > > It send a DM to interested users, but maybe using Outgoing WebHooks the DM > can be forwarded to some service to publish it. > > > > 2015-11-30 17:47 GMT-03:00 philippe.back(a)highoctane.be > <philippe.back(a)gmail.com>: >> >> And I've not been looking at Slack that much. >> >> Digest would be we nice indeed. >> >> Phil >> >> On Nov 30, 2015 4:53 AM, "EuanM" <euanmee(a)gmail.com> wrote: >>> >>> And of course, we can stop doing it manually once threading arrives. >>> >>> On 30 November 2015 at 03:52, EuanM <euanmee(a)gmail.com> wrote: >>> > I have been talking to the Slack dev team and they assure me that >>> > threading is on its way - as a priority. >>> > >>> > I am happy to manually curate threads if someone gets a 24hour dump to >>> > log files working. >>> > >>> > The best way to do this would be to have teams of curators per >>> > channel, each doing a little curation periodically on a rota per >>> > channel basis. >>> > >>> > This is an ideal task for people still getting up to speed with Pharo >>> > internals. It is a great way to be exposed to stuff you don't >>> > understand, and put your mind around it. >>> > >>> > This provide a starter slope for future contributors. >>> > >>> > On 23 November 2015 at 08:14, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> >>> > wrote: >>> >> The problem is, that it is not that easy to create a âdigestâ from >>> >> Slack, as there is no kind of grouping. Either you have to detect similar >>> >> words in discussion, or you have to simply export everything. I donât know >>> >> whether it makes sense to just compose a huge email of all discussions, but >>> >> we can try to do that. >>> >> >>> >> Cheers. >>> >> Uko >>> >> >>> >>> On 23 Nov 2015, at 00:21, EuanM <euanmee(a)gmail.com> wrote: >>> >>> >>> >>> I agree - if we can have each 24 hours of chat archived to somewhere >>> >>> that provides a free-text search, that would be very good. >>> >>> >>> >>> Up until now, I've been grabbing, editting and posting chats I find >>> >>> of >>> >>> interest and importance to me. And it seems to lend itself to design >>> >>> discussions. What it's not very good at, atm, is discussion >>> >>> threading. It would be great to be able to set your typing as >>> >>> belonging to a thread., so that when it get sucked out and archived >>> >>> that the threads were segregated. >>> >>> >>> >>> Does someone have a server that could receive a text dump of all >>> >>> recent Slack messages every 12 (or 24, or 6) hours, and then make it >>> >>> available for indexing by Google et al, and querying (via the search >>> >>> engines) by our dev base? >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On 22 November 2015 at 13:57, Dimitris Chloupis >>> >>> <kilon.alios(a)gmail.com> wrote: >>> >>>> Just to clear something up , because I see people in slack saying >>> >>>> goodbye, >>> >>>> or "I cant reply right now I have something to do" . Slack is not >>> >>>> just a >>> >>>> real time chat, it keeps messages inside a history of 10 thousand >>> >>>> messages. >>> >>>> So that means you can log in Slack at any time and not lose a >>> >>>> message. There >>> >>>> is no reason for you to be online all time, no reason to say >>> >>>> goodbye, >>> >>>> goodmorning , goodafternoon. You can come and go as you please the >>> >>>> exact >>> >>>> same way as the mailing list. >>> >>>> >>> >>>> The problem arises when we exceed 10k messages, the old ones get >>> >>>> lost and I >>> >>>> think having a place to store them is a good idea. >>> >>>> >>> >>>> Also what is important is in the eye of the beholder, for example I >>> >>>> dont >>> >>>> care about any discussion about web development , its just does not >>> >>>> interest >>> >>>> me or database coding or many other things. I have learned to filter >>> >>>> out the >>> >>>> messages I dont care about in the mailing list and just reject them. >>> >>>> Slack >>> >>>> is same story, I quickly glance through its history and I can search >>> >>>> the >>> >>>> messages that interest me using the search bar , I can star messages >>> >>>> that I >>> >>>> want to keep, and I can comment on existing messages / code snippets >>> >>>> which >>> >>>> create a thread about that message. >>> >>>> >>> >>>> In the end its impossible to keep the community in one place but to >>> >>>> have a >>> >>>> central hub that collects all the little gems can be quite useful. >>> >>>> >>> >>>> On Sun, Nov 22, 2015 at 3:46 PM stepharo <stepharo(a)free.fr> wrote: >>> >>>>> >>> >>>>> Yes this would be good. >>> >>>>> People should understand that important discussions should be via >>> >>>>> the >>> >>>>> mailing-list. >>> >>>>> Emails are good because you can consume them the way you want. >>> >>>>> I simply cannot be connected all the time. So emails are good >>> >>>>> because I >>> >>>>> can process them >>> >>>>> when I decide. >>> >>>>> Slack is good for more interactive session around debugger and >>> >>>>> things >>> >>>>> like that. >>> >>>>> >>> >>>>> Stef >>> >>>>> >>> >>>>> >>> >>>>> Le 21/11/15 18:05, Stephan Eggermont a Ã©crit : >>> >>>>>> Should we have a digest from slack to a mailing list? >>> >>>>>> We are already losing messages >>> >>>>>> >>> >>>>>> Stephan >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>> >>> >>>>> >>> >>>> >>> >>> >>> >> >>> >> >>> >

Dec. 2, 2015

Re: [Pharo-dev] Digest from slack to the mailing list?

by GastÃ³n Dall' Oglio

Hello. Just a thought ... There's a automated tool for do that (I have not tried yet) http://slackdigest.com/digest.html It send a DM to interested users, but maybe using Outgoing WebHooks the DM can be forwarded to some service to publish it. 2015-11-30 17:47 GMT-03:00 philippe.back(a)highoctane.be < philippe.back(a)gmail.com>: > And I've not been looking at Slack that much. > > Digest would be we nice indeed. > > Phil > On Nov 30, 2015 4:53 AM, "EuanM" <euanmee(a)gmail.com> wrote: > >> And of course, we can stop doing it manually once threading arrives. >> >> On 30 November 2015 at 03:52, EuanM <euanmee(a)gmail.com> wrote: >> > I have been talking to the Slack dev team and they assure me that >> > threading is on its way - as a priority. >> > >> > I am happy to manually curate threads if someone gets a 24hour dump to >> > log files working. >> > >> > The best way to do this would be to have teams of curators per >> > channel, each doing a little curation periodically on a rota per >> > channel basis. >> > >> > This is an ideal task for people still getting up to speed with Pharo >> > internals. It is a great way to be exposed to stuff you don't >> > understand, and put your mind around it. >> > >> > This provide a starter slope for future contributors. >> > >> > On 23 November 2015 at 08:14, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> >> wrote: >> >> The problem is, that it is not that easy to create a âdigestâ from >> Slack, as there is no kind of grouping. Either you have to detect similar >> words in discussion, or you have to simply export everything. I donât know >> whether it makes sense to just compose a huge email of all discussions, but >> we can try to do that. >> >> >> >> Cheers. >> >> Uko >> >> >> >>> On 23 Nov 2015, at 00:21, EuanM <euanmee(a)gmail.com> wrote: >> >>> >> >>> I agree - if we can have each 24 hours of chat archived to somewhere >> >>> that provides a free-text search, that would be very good. >> >>> >> >>> Up until now, I've been grabbing, editting and posting chats I find of >> >>> interest and importance to me. And it seems to lend itself to design >> >>> discussions. What it's not very good at, atm, is discussion >> >>> threading. It would be great to be able to set your typing as >> >>> belonging to a thread., so that when it get sucked out and archived >> >>> that the threads were segregated. >> >>> >> >>> Does someone have a server that could receive a text dump of all >> >>> recent Slack messages every 12 (or 24, or 6) hours, and then make it >> >>> available for indexing by Google et al, and querying (via the search >> >>> engines) by our dev base? >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> On 22 November 2015 at 13:57, Dimitris Chloupis < >> kilon.alios(a)gmail.com> wrote: >> >>>> Just to clear something up , because I see people in slack saying >> goodbye, >> >>>> or "I cant reply right now I have something to do" . Slack is not >> just a >> >>>> real time chat, it keeps messages inside a history of 10 thousand >> messages. >> >>>> So that means you can log in Slack at any time and not lose a >> message. There >> >>>> is no reason for you to be online all time, no reason to say goodbye, >> >>>> goodmorning , goodafternoon. You can come and go as you please the >> exact >> >>>> same way as the mailing list. >> >>>> >> >>>> The problem arises when we exceed 10k messages, the old ones get >> lost and I >> >>>> think having a place to store them is a good idea. >> >>>> >> >>>> Also what is important is in the eye of the beholder, for example I >> dont >> >>>> care about any discussion about web development , its just does not >> interest >> >>>> me or database coding or many other things. I have learned to filter >> out the >> >>>> messages I dont care about in the mailing list and just reject them. >> Slack >> >>>> is same story, I quickly glance through its history and I can search >> the >> >>>> messages that interest me using the search bar , I can star messages >> that I >> >>>> want to keep, and I can comment on existing messages / code snippets >> which >> >>>> create a thread about that message. >> >>>> >> >>>> In the end its impossible to keep the community in one place but to >> have a >> >>>> central hub that collects all the little gems can be quite useful. >> >>>> >> >>>> On Sun, Nov 22, 2015 at 3:46 PM stepharo <stepharo(a)free.fr> wrote: >> >>>>> >> >>>>> Yes this would be good. >> >>>>> People should understand that important discussions should be via >> the >> >>>>> mailing-list. >> >>>>> Emails are good because you can consume them the way you want. >> >>>>> I simply cannot be connected all the time. So emails are good >> because I >> >>>>> can process them >> >>>>> when I decide. >> >>>>> Slack is good for more interactive session around debugger and >> things >> >>>>> like that. >> >>>>> >> >>>>> Stef >> >>>>> >> >>>>> >> >>>>> Le 21/11/15 18:05, Stephan Eggermont a Ã©crit : >> >>>>>> Should we have a digest from slack to a mailing list? >> >>>>>> We are already losing messages >> >>>>>> >> >>>>>> Stephan >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>> >> >>>>> >> >>>> >> >>> >> >> >> >> >> >>

Dec. 2, 2015

Re: [Pharo-dev] #sum:, #detectSum:, #sumNumbers:

by Ben Coman

On Wed, Dec 2, 2015 at 12:38 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > >> On Dec 1, 2015, at 5:13 PM, Max Leske <maxleske(a)gmail.com> wrote: >> >> @Doru >> Youâre missing the point: #anyOne *fails* for empty collections. > > I am not missing the point at all. I am saying that if you want sum: to be generic, it cannot assume a specific Zero object. > > And sum: should be generic because of its name. I am missing understanding the other use cases. Can you describe further the generic nature of #sum & #sum: ? I would have thought by default they only applied to numbers. cheers -ben > >>> On 01 Dec 2015, at 15:31, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: >>> >>> I don't want to be heretic (or too orthodox), but why not to delegate >>> this behavior to other class (an iterator maybe?). >>> >>> It's too tempting adding these convenience methods to Collection >>> and/or subclasses, but anything that requires an explicit protocol of >>> its elements is wrong, IMO. >>> >>> something like aCollection arithmetic sum: [...] or.... aCollection >>> arithmetic avg. >> >> >> Interesting thought! > > +100 > > Doru > >>> >>> My two cents for this. >>> >>> Regards! >>> >>> >>> Esteban A. Maringolo >>> >> >> > > -- > www.tudorgirba.com > > "Every thing has its own flow." > > > > >

Dec. 2, 2015

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

by webwarrior

Case 16725 - Merge changes from spec github repository. 2 subcases are resolved, 2 other need decision. Nothing time-consuming - just decide if we integrate them or mark as wontfix. Case 15927 - Menu is broken when contained in a list. This is much more complicated, it's even not clear which class (TransfromMorph or MenuItemMorph) is bugged. I tried to fix it myself, but had no success. -- View this message in context: http://forum.world.st/Help-needed-old-issues-issue-tracker-entries-tp486426… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Dec. 2, 2015

[pharo-project/pharo-core] 49cb98: 50481

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 49cb988a0b150e3b14a5cd420fac37dad93f5f4c https://github.com/pharo-project/pharo-core/commit/49cb988a0b150e3b14a5cd42… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-12-02 (Wed, 02 Dec 2015) Changed paths: A Morphic-Base.package/SelectionMorph.class/instance/submorphs-add%2Fremove/goBehind.st M Nautilus.package/AbstractNautilusUI.class/instance/menus behavior/browseMessages.st R OpalCompiler-Core.package/OCBytecodeEncodingError.class/README.md R OpalCompiler-Core.package/OCBytecodeEncodingError.class/definition.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50480.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50481.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50480.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50481.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A Spec-Core.package/ComposableModel.class/instance/widgets/newDiff.st A Spec-Tools.package/MessageBrowser.class/instance/accessing/textModel_.st M Spec-Tools.package/VersionBrowser.class/instance/instance creation/showDiffMorphWithConverter_.st M Spec-Tools.package/VersionBrowser.class/instance/instance creation/showSourceWithConverter_.st Log Message: ----------- 50481 17165 OCBytecodeEncodingError is not used --> remove https://pharo.fogbugz.com/f/cases/17165 15508 SelectionMorph send to back https://pharo.fogbugz.com/f/cases/15508 14845 Selecting a class and pressing command B+M raises an error https://pharo.fogbugz.com/f/cases/14845 15678 Remove ComposableModel>>#instantiateModels:s senders in NewVersionBrowser https://pharo.fogbugz.com/f/cases/15678 http://files.pharo.org/image/50/50481.zip

Dec. 2, 2015

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50481 Home: https://github.com/pharo-project/pharo-core

Dec. 2, 2015

Re: [Pharo-dev] #sum:, #detectSum:, #sumNumbers:

by Max Leske

Even though we havenât been able to completely agree on the resolution, I feel we can agree that we need to change something. Iâve opened an issue and copied the messages from this thread into it for documentation. https://pharo.fogbugz.com/f/cases/17174/Unify-sum-sum-sumNumbers-and-detect… Cheers, Max > On 01 Dec 2015, at 18:41, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > >> On 01 Dec 2015, at 17:43, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >> Hi, >> >>> On Dec 1, 2015, at 3:24 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>> Doru, >>> >>>> On 01 Dec 2015, at 15:11, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>>> >>>> Hi, >>>> >>>>> On Dec 1, 2015, at 12:52 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>>> >>>>> >>>>>> On 01 Dec 2015, at 12:45, Stephan Eggermont <stephan(a)stack.nl> wrote: >>>>>> >>>>>> On 01-12-15 11:46, Sven Van Caekenberghe wrote: >>>>>>> The basic question for me is, what should >>>>>>> >>>>>>> #() sum >>>>>>> >>>>>>> return. Right now, it is an error, I would very much like that for this common case the result would be 0. There is a lot of power (easy of use) in a unary selector, we should not destroy that with semantics that force a test before using it. >>>>>> >>>>>> I like the error, it aligns with most of our collection protocol. >>>>> >>>>> I hate the error, a lot ;-) >>>>> >>>>>> It shows the need for #sum:ifEmpty: though >>>>> >>>>> Yes, as long as #() sum == 0 >>>> >>>> That wonât work :). >>> >>> Why ? Please explain. >>> >>>>> I want the simplest case to be simple, having a non-0 default is a special case IMHO >>>> >>>> That is why you have sumNumbers:. We could also add Collection>>sumNumbers. >>>> >>>> We had this discussion at length before Pharo 4, and this is when we agreed to add sumNumbers: and let sum: be generic (like the name says it should be) and not assume that it should work with Numbers. >>> >>> It is not about numbers or not, you are still using #+ in your generic case, that is numeric in my book. It is about the zero element and how to deal with an empty collection. >>> >>> The current solution, which was indeed recently added, leaves the problem of what to do with an empty collection. There is no general solution, you have to specify a zero element. >> >> Exactly. >> >>> But for most people in most cases that will be effectively 0, so lets make the unary #sum respect that. (And unary #sum will also work for non-empty non-zero based objects). The less common case can then use the longer message. >> >> You said it correctly: âmostâ :). That is why, a generic meaning should be left generic and provide a solution that will work with âallâ cases :). >> >> Itâs a matter of choice, but sum: has a too generic meaning to have it confined to numbers. > > I think we all mean the same thing and understand each other's point. > > But the first meaning of 'sum' in Wikipedia leads to https://en.wikipedia.org/wiki/Summation which talks about numbers. I studied partly Mathematics, so I know there are different numeric systems and abstractions. My point is: the common case is adding (simple) numbers, the special case is the more general one, hence the best selector, #sum, should work for the common case, including for the empty one. > > Consider also Ben's link: > > https://en.wikipedia.org/wiki/Empty_sum > > Hence my suggestion to change #sum to > > | sum sample | > self isEmpty ifTrue: [ ^ 0 ]. > sample := self anyOne. > sum := self inject: sample into: [ :accum :each | accum + each ]. > ^ sum - sample > > And the same for #sum: > > Note that the above *will* work for all like today, just not if they are empty. Now, of course we will need the ifEmpty: variants for what I consider the less common cases. > > Can I also remark that both #inject:into: and #fold: are perfectly fine for more involved cases. We have a lot of API ;-) > >> Cheers, >> Doru >> >>>> Cheers, >>>> Doru >>>> >>>>> >>>>>> Stephan >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> -- >>>> www.tudorgirba.com >>>> >>>> "Speaking louder won't make the point worthier." >>> >>> >> >> -- >> www.tudorgirba.com >> >> "Next time you see your life passing by, say 'hi' and get to know her." > >

Dec. 2, 2015

issue 12231 DisplayScreen hostWindowTitle: not working on Linux (ubuntu)

by Nicolai Hess

see bug report 12231, I added a fix for the unix config. But it has to applied by someone. (I don't know where to put this else). But the issue is two years old, if no one responds, I'll just close the issue.

Dec. 1, 2015