- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Tricky Metaclass>>binding

by Stephane Ducasse

At the minimum having classBinding instead of GlobalBinding would be already a good step. Then since the metaclass and the class are a real couple could we not have an object shared by both (but it would cost one indirection). On Tue, Sep 12, 2017 at 5:33 PM, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > I don't know... I found the idea of having a Metaclass binding strange... > > I mean, > - metaclasses are not stored in any name dictionary such as Smalltalk > - nobody references them directly in source code but by their direct classes > > The metaclass binding is there just for one thing really: methods need an > association to know their class in case they have to do a super send. And > transitively this is a compiler problem also. But anybody else accesses > metaclasses' bindings.

Sept. 13, 2017

Re: [Pharo-dev] Maybe better pinning messages? (inspired by [Pinning Objects in Pharo])

by Denis Kudriashov

Hi Eliot. I know and I only talk about new messages. I am not trying to rethink full meta model of Smalltalk. By the way #class is very common message and it is handy to use short name. But pinning messages will be used rarely in very specific applications. So no much sense to preserve them in short version. 2017-09-12 18:05 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > Hi Denis, > > > On Sep 12, 2017, at 2:39 AM, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > > I am really wonder guys. I thought you are not big funs of Object protocol. > Current pinning messages are a new set of very generic messages in the > Object. > > > Yes, and that's because this is a fundamental property of all > non-immediate objects. Do you object to the #class message? Should it be > #classObject because it might conflict with #class used in an educational > or socioeconomic model? All objects other than immediates can move. > Pinning stops that movement. It applies generally. So the protocol > belongs in Object. > > > > About Norbert idea. > - bePinnedObject is not bad convention. But I would prefer the memory > suffix because it reflects the low level behaviour. > > 2017-09-11 14:16 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > >> yes, me :) >> >> I do not see a reason to change them, tbh. >> for me they are comprensible as they are now and it does not adds more >> information pinInMemory or pinMemory. >> >> Esteban >> >> >> On 11 Sep 2017, at 11:56, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: >> >> Anybody else? >> >> 2017-08-31 10:29 GMT+02:00 Pavel Krivanek <pavel.krivanek(a)gmail.com>: >> >>> >>> >>> 2017-08-31 10:24 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: >>> >>>> Hi. >>>> >>>> We now have very generic message names: >>>> - pin >>>> - unpin >>>> - setPinned: >>>> - isPinned >>>> >>>> Problem that they collide with possible domain related names. >>>> For example I implemented pinning of tabs in Calypso and I found that I >>>> overrides #pin and #isPinned messages. Then I fix it with different names. >>>> Probably menus also uses pin word but without overrides >>>> >>>> What you think about renaming pinning messages? Something like: >>>> - pinMemory >>>> >>> >>> I would use pinInMemory >>> >>> -- Pavel >>> >>> >>>> - unpinMemory >>>> - isMemoryPinned >>>> - setPinnedMemory: >>>> - pinMemoryDuring: (if we will introduce it) >>>> >>>> I think it is easy to do now because not much code uses pinning >>>> >>> >>> >> >> >

Sept. 12, 2017

Re: [Pharo-dev] Maybe better pinning messages? (inspired by [Pinning Objects in Pharo])

by Eliot Miranda

Hi Denis, > On Sep 12, 2017, at 2:39 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > I am really wonder guys. I thought you are not big funs of Object protocol. > Current pinning messages are a new set of very generic messages in the Object. Yes, and that's because this is a fundamental property of all non-immediate objects. Do you object to the #class message? Should it be #classObject because it might conflict with #class used in an educational or socioeconomic model? All objects other than immediates can move. Pinning stops that movement. It applies generally. So the protocol belongs in Object. > > About Norbert idea. > - bePinnedObject is not bad convention. But I would prefer the memory suffix because it reflects the low level behaviour. > > 2017-09-11 14:16 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: >> yes, me :) >> >> I do not see a reason to change them, tbh. >> for me they are comprensible as they are now and it does not adds more information pinInMemory or pinMemory. >> >> Esteban >> >> >>> On 11 Sep 2017, at 11:56, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: >>> >>> Anybody else? >>> >>> 2017-08-31 10:29 GMT+02:00 Pavel Krivanek <pavel.krivanek(a)gmail.com>: >>>> >>>> >>>> 2017-08-31 10:24 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: >>>>> Hi. >>>>> >>>>> We now have very generic message names: >>>>> - pin >>>>> - unpin >>>>> - setPinned: >>>>> - isPinned >>>>> >>>>> Problem that they collide with possible domain related names. >>>>> For example I implemented pinning of tabs in Calypso and I found that I overrides #pin and #isPinned messages. Then I fix it with different names. >>>>> Probably menus also uses pin word but without overrides >>>>> >>>>> What you think about renaming pinning messages? Something like: >>>>> - pinMemory >>>> >>>> I would use pinInMemory >>>> >>>> -- Pavel >>>> >>>>> - unpinMemory >>>>> - isMemoryPinned >>>>> - setPinnedMemory: >>>>> - pinMemoryDuring: (if we will introduce it) >>>>> >>>>> I think it is easy to do now because not much code uses pinning >>>> >>> >> >

Sept. 12, 2017

Re: [Pharo-dev] Maybe better pinning messages? (inspired by [Pinning Objects in Pharo])

by H. Hirzel

On 9/12/17, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > I am really wonder guys. I thought you are not big funs of Object protocol. > Current pinning messages are a new set of very generic messages in the > Object. > > About Norbert idea. > - bePinnedObject is not bad convention. >But I would prefer the memory > suffix because it reflects the low level behaviour. +1 > 2017-09-11 14:16 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > >> yes, me :) >> >> I do not see a reason to change them, tbh. >> for me they are comprensible as they are now and it does not adds more >> information pinInMemory or pinMemory. >> >> Esteban >> >> >> On 11 Sep 2017, at 11:56, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: >> >> Anybody else? >> >> 2017-08-31 10:29 GMT+02:00 Pavel Krivanek <pavel.krivanek(a)gmail.com>: >> >>> >>> >>> 2017-08-31 10:24 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: >>> >>>> Hi. >>>> >>>> We now have very generic message names: >>>> - pin >>>> - unpin >>>> - setPinned: >>>> - isPinned >>>> >>>> Problem that they collide with possible domain related names. >>>> For example I implemented pinning of tabs in Calypso and I found that I >>>> overrides #pin and #isPinned messages. Then I fix it with different >>>> names. >>>> Probably menus also uses pin word but without overrides >>>> >>>> What you think about renaming pinning messages? Something like: >>>> - pinMemory >>>> >>> >>> I would use pinInMemory >>> >>> -- Pavel >>> >>> >>>> - unpinMemory >>>> - isMemoryPinned >>>> - setPinnedMemory: >>>> - pinMemoryDuring: (if we will introduce it) >>>> >>>> I think it is easy to do now because not much code uses pinning >>>> >>> >>> >> >> >

Sept. 12, 2017

Re: [Pharo-dev] Tricky Metaclass>>binding

by Guillermo Polito

I don't know... I found the idea of having a Metaclass binding strange... I mean, - metaclasses are not stored in any name dictionary such as Smalltalk - nobody references them directly in source code but by their direct classes The metaclass binding is there just for one thing really: methods need an association to know their class in case they have to do a super send. And transitively this is a compiler problem also. But anybody else accesses metaclasses' bindings. â

Sept. 12, 2017

Re: [Pharo-dev] About Git support for windows

by Peter UhnÃ¡k

> > Just a random idea, how about each time writing timestamps to > a different file name "timestamps.$HashOfClassSourceFile" > Then git would never complain of a conflict(??). > If I understand your proposal correctly, that would imo result in the following: accumulating endless list of timestamps.XXX files (there are no conflicts and thus no mechanism to get rid of them) still having conflict, because the #sourceHash is different (any two independent changes to a line will trigger conflict) plus added complexity and a lot more reading/processing CPU/disk required P

Sept. 12, 2017

[OOPS @ SAC 2018] Extended submission deadline: Sept. 25

by Nick Papoylias

************************************************** OOPS 2018 Call for Papers Object-Oriented Programming Languages and Systems http://oops.disi.unige.it/OOPS18 ************************************************** Technical Track at the 33rd ACM Symposium on Applied Computing, SAC 2018 https://www.sigapp.org/sac/sac2018/index.html April 9 - 13, 2018 Pau, France - Important Dates Submission of regular papers and SRC abstracts *September 25, 2017 (extended deadline)* Paper and SRC notifications November 10, 2017 Paper and SRC camera-ready copies November 25, 2017 Author registration December 10, 2017 SAC 2018 April 9 - 13, 2018 - Track Chair Davide Ancona (davide.ancona(a)unige.it) DIBRIS, University of Genova, Italy - SAC 2018 For the past thirty two years, the ACM Symposium on Applied Computing (SAC) has been a primary gathering forum for applied computer scientists, computer engineers, software engineers, and application developers from around the world. SAC 2018 is sponsored by the ACM Special Interest Group on Applied Computing (SIGAPP) and is hosted by hosted by UniversitÃ© de Pau et des Pays de l'Adour (UPPA), Pau, France. - Call For Student Research Abstracts Graduate students seeking feedback from the scientific community on their research ideas are invited to submit original abstracts of their research work in areas of experimental computing and application development related to SAC 2018 Tracks. The Student Research Competition (SRC) Program is designed to provide graduate students the opportunity to meet and exchange ideas with researchers and practitioners in their areas of interest. - OOPS Track: Aims and Topics Object-oriented programming (OOP) has become the mainstream programming paradigm for developing complex software systems in most application domains. However, existing OO languages and platforms need to evolve to meet the continuous demand for new abstractions, features, and tools able to reduce the time, effort, and cost of creating object-oriented software systems, and improving their performance, quality and usability. To this aim, OOPS is seeking for research advances bringing benefits in all those typical aspects of software development, such as modeling, prototyping, design, implementation, concurrency and distribution, code generation, analysis, verification, testing, debugging, evaluation, deployment, maintenance, reuse, and software evolution and adaptation. The specific topics of interest for the OOPS track include, but are not limited to, the following: * Aspects and components * Code generation, and optimization, just-in-time compilation * Context-oriented programming * Databases and persistence * Distribution and concurrency * Dynamic and scripting languages * Evaluation * Feature Oriented Software Development and Programming * Formal verification * Internet of Things technology and programming * Integration with other paradigms * Interoperability, versioning and software evolution and adaptation * Language design and implementation * Modular and generic programming * Reflection, meta-programming * Runtime verification and monitoring * Safe, secure and dependable software * Static analysis * Testing and debugging * Type systems and type inference * Virtual machines OOPS offers a great opportunity to the OOP community to gain visibility, and to exploit the inter-disciplinary nature of SAC. - Submission Instructions Prospective papers should be submitted to the track in pdf format using the START submission system for regular and SRC papers available through the SAC 2018 home page. Submission of the same paper to multiple tracks is not allowed; all papers should represent original and previously unpublished works that are currently not under review in any conference or journal. Both basic and applied research papers are welcome. SAC 2018 will use double-blind reviewing; to facilitate this, author name(s) and institution(s) must be omitted, and references to authors' own related work should be in the third person. The format of the paper must adhere to the sig-alternate style (http://www.acm.org/sigs/publications/proceedings-templates) Full papers are limited to 8 pages, in camera-ready format, included in the registration fee. Authors have the option to include up to two (2) extra pages at additional fee of US$80 per page. Papers accepted as posters are limited to 3 pages, in camera-ready format, included in the registration fee. Authors have the option to include only one (1) extra page at additional fee of US$80. SRC abstracts are limited to 2 pages, in camera-ready format, included in the registration fee. No extra pages are allowed. Papers that fall short the above requirements are subjected to rejection. All papers must be submitted by September 15, 2017. For more information please visit the SAC 2018 home page. - Proceedings Accepted papers will be published by ACM in the annual conference proceedings. Accepted posters will be published as extended abstracts in the same proceedings. Paper registration is required, allowing the inclusion of the papers and posters in the conference proceedings. An author or a proxy attending SAC MUST present the paper. This is a requirement for all accepted papers, posters, and invited SRC submissions to be included in the ACM digital library. No-show of scheduled papers, posters, and student research abstracts will result in excluding them from the ACM digital library. Student registration is only intended to encourage student attendance and does not cover inclusion of papers/posters in the conference proceedings. Finally, following the tradition of the past OOPS editions (http://oops.disi.unige.it/special-issues) depending on the quality and the overall number of accepted papers, authors of selected papers will be invited to submit an extended version for a journal special issue ( http://oops.disi.unige.it/special-issues) after the conference.

Sept. 12, 2017

Re: [Pharo-dev] About Git support for windows

by Ben Coman

On Sun, Sep 10, 2017 at 5:06 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > On 10 Sep 2017, at 10:56, Henrik-Nergaard <draagren(a)outlook.com> wrote: > > Everyone who used filetree with metadata can tell it is super annoying and > > destroys the complete experience. > There has been a fix for this on the issue tracker for some time: > https://pharo.fogbugz.com/f/cases/20251/Write-out-filetree- > metadata-in-order > > > thatâs not related. Timestamp conflicts are related two different users > touching exactly same part of source: conflict guaranteed, no matter the > order. > Just a random idea, how about each time writing timestamps to a different file name "timestamps.$HashOfClassSourceFile" Then git would never complain of a conflict(??). I haven't thought that through a lot. I guess with a git merge you end up with two "timestamps" files with different stamps for the same method so its unclear which to use - so the timestamps file might include the hash of the method source, so regardless of the mechanism to merge the ClassSourceFile, you can work back to the timestamp. For example... Morph class>>announcer { #sourceHash : '264011013dab93d02fb5c0f0f68eaa64063bc750', #category : #accessing, #timestamp : ' 8/31/2017 05:26:11' } where... (SHA1 new hashMessage: '[ ^ announcer ifNil: [ announcer := Announcer new ]. ]') hex " ==> '264011013dab93d02fb5c0f0f68eaa64063bc750' " Maybe a lot of holes in the idea, but I thought it worth stimulating a few neurons out there. cheers -ben > btw, Tonel export order is deterministic and it will always output same > data in same way. > > Esteban > > > Best regards, > Henrik > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > > >

Sept. 12, 2017

Re: [Pharo-dev] Tricky Metaclass>>binding

by Marcus Denker

> On 12 Sep 2017, at 11:32, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > I found interesting trick in system: the way how class side perform #binding message: > > Metaclass>>binding > "return an association that can be used as the binding > To share it between methods, reuse an existing one if possible" > ^self methodDict > ifEmpty: [nil -> self] > ifNotEmpty: [:dict | dict anyOne classBinding] > > It leads to interesting behaviour of class without class side methods: > > NewClass class binding == NewClass class binding "==> false" > > Generally I discovered in the logic which decode class of method in last literal. Interesting that for instance side methods it is always represented by GlobalVariable. And for class side methods it is always general Association. > > Can we make this behaviour more consistent? And will it improve the system? (I thing about possible complications to bootstrap). > > As solution I would introduce new kind of LiteralVariable: ClassBinding with two subclasses InstanceSideBinding and ClassSideBinding. They will take place in last method literal. > InstanceSideBinding will be used in Smalltalk dictionary for classes instead of GlobalVariable. > And it will keep variable with class side binding. So the trick will be not needed anymore. > > So what do you think? It would be nice to improve it.. I like the idea of a ClassBinding subclass (this way it is distinct from Global Vars, too). The only question of adding one ivar to ca. 5000 Objects is not too much.. do we get enough out of it for that amount of memory? Maybe there is some other possibility? Marcus

Sept. 12, 2017

Re: [Pharo-dev] Maybe better pinning messages? (inspired by [Pinning Objects in Pharo])

by Denis Kudriashov

I am really wonder guys. I thought you are not big funs of Object protocol. Current pinning messages are a new set of very generic messages in the Object. About Norbert idea. - bePinnedObject is not bad convention. But I would prefer the memory suffix because it reflects the low level behaviour. 2017-09-11 14:16 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > yes, me :) > > I do not see a reason to change them, tbh. > for me they are comprensible as they are now and it does not adds more > information pinInMemory or pinMemory. > > Esteban > > > On 11 Sep 2017, at 11:56, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > Anybody else? > > 2017-08-31 10:29 GMT+02:00 Pavel Krivanek <pavel.krivanek(a)gmail.com>: > >> >> >> 2017-08-31 10:24 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: >> >>> Hi. >>> >>> We now have very generic message names: >>> - pin >>> - unpin >>> - setPinned: >>> - isPinned >>> >>> Problem that they collide with possible domain related names. >>> For example I implemented pinning of tabs in Calypso and I found that I >>> overrides #pin and #isPinned messages. Then I fix it with different names. >>> Probably menus also uses pin word but without overrides >>> >>> What you think about renaming pinning messages? Something like: >>> - pinMemory >>> >> >> I would use pinInMemory >> >> -- Pavel >> >> >>> - unpinMemory >>> - isMemoryPinned >>> - setPinnedMemory: >>> - pinMemoryDuring: (if we will introduce it) >>> >>> I think it is easy to do now because not much code uses pinning >>> >> >> > >

Sept. 12, 2017