Re: [Pharo-dev] Immutability support

The "CAN'T REACH" comment is there because execution never reach that part of the code. If you write code there, it will never be executed. The process code performs a return without pushing any value on stack. Signalling an error is safe if the error is never resumed. But you'll need the

Re: [Pharo-dev] memoized vs once

Oops, forgive me Ben. I'm wrong. once is only equivalent to memoized for nullary blocks. It is not the same as memoized:[value:] for N-ary blocks. Forgive the noise. _,,,^..^,,,_ (phone) > On Jan 25, 2017, at 10:56 AM, Eliot Miranda wrote: > > Hi Ben, > >

Re: [Pharo-dev] memoized vs once

There is the memoized with the internally declared Dictionary new as the cache and memoized using: cache There cache is known and the result is a block that does the caching thing. ([ :cacheKey| self getIssueCreateMetaWithExpandKeys: true ] memoizedUsing: self cache) value: #issueCreateMeta

Re: [Pharo-dev] memoized vs once

On 26 January 2017 at 02:10, p...@highoctane.be wrote: > Ah ah :-D > > DynamicVariables are darker magic that this, right? > > you mean like those that seaside using? it lives as long as session lives, and tied to session you are working in.. in early versions of seaside they

Re: [Pharo-dev] memoized vs once

On 26 January 2017 at 02:10, p...@highoctane.be wrote: > Ah ah :-D > > In my example I want to be able to do the calls without caching or with > caching. Without for debugging because I amend the server side at times and > want always fresh data (yes, I could have a cache

Re: [Pharo-dev] memoized vs once

Ah ah :-D In my example I want to be able to do the calls without caching or with caching. Without for debugging because I amend the server side at times and want always fresh data (yes, I could have a cache with TTL of about nothing). Memoization is useful for not having to write the caching

Re: [Pharo-dev] memoized vs once

Because caching are always comes with concerns, like when/where do we want to drop cached results and recalculate them, if needed.. With memoization it seems like there's simply no such concern at all.. meaning that cached data will live forever since created once.. which is never good for dynamic

Re: [Pharo-dev] memoized vs once

On 26 January 2017 at 01:40, p...@highoctane.be wrote: > Yeah, I get you 100%. > > I wanted to be able to cache or not and have this transparent. > > Memoization in its current form in Pharo is not like I would like to have > it. > > As for the repeating block, I was asking

Re: [Pharo-dev] memoized vs once

Yeah, I get you 100%. I wanted to be able to cache or not and have this transparent. Memoization in its current form in Pharo is not like I would like to have it. As for the repeating block, I was asking to how you would avoid repeating in the given code structure. Phil On Thu, Jan 26, 2017

Re: [Pharo-dev] memoized vs once

On 26 January 2017 at 01:33, p...@highoctane.be wrote: > self memoize: #methodThatDoesSomethingLong:. > > would automatically store parameters values as cache keys. No matter how > many such parms. > > No need to have blocks or anything,operations are memoized. > We use

Re: [Pharo-dev] memoized vs once

self memoize: #methodThatDoesSomethingLong:. would automatically store parameters values as cache keys. No matter how many such parms. No need to have blocks or anything,operations are memoized. We use blocks for lack of a better way right now I guess. Phil On Thu, Jan 26, 2017 at 12:22 AM,

Re: [Pharo-dev] memoized vs once

On 26 January 2017 at 01:23, p...@highoctane.be wrote: > Nothing new, that's the term. > > Memoization: After computing a solution to a subproblem, store it in a > table. Subsequent calls check the table to avoid redoing work. > > https://en.wikipedia.org/wiki/Memoization > >

Re: [Pharo-dev] memoized vs once

But for caching you have a cache. The whole point of memoization support is to have it easy to do. Look at the bottom of this page: http://wiki.tcl.tk/10981 So if we could have some kind of the same using manipulation of thisContext and/or Slots, it would be nicer. e.g. SomeClass>>#initialize

Re: [Pharo-dev] memoized vs once

Nothing new, that's the term. Memoization: After computing a solution to a subproblem, store it in a table. Subsequent calls check the table to avoid redoing work. https://en.wikipedia.org/wiki/Memoization http://www.cas.mcmaster.ca/~deza/6_Dynamic++.pdf http://wiki.tcl.tk/10779 I have been

Re: [Pharo-dev] memoized vs once

result := [ do something long or short or whatever] cached. On 26 January 2017 at 01:20, Igor Stasenko wrote: > > > On 26 January 2017 at 01:14, p...@highoctane.be > wrote: > >> If one is doing any dynamic programming, the memoization term is pretty >>

Re: [Pharo-dev] memoized vs once

On 26 January 2017 at 01:14, p...@highoctane.be wrote: > If one is doing any dynamic programming, the memoization term is pretty > natural. > > for that purpose, i naturally using 'caching' wording. > https://youtu.be/OQ5jsbhAv_M?t=3m11s > > Phil > > On Wed, Jan 25, 2017 at

Re: [Pharo-dev] memoized vs once

Underscore.js names it also #memoize. http://underscorejs.org/#memoize Cheers On Jan 26, 2017 00:15, "p...@highoctane.be" wrote: If one is doing any dynamic programming, the memoization term is pretty natural. https://youtu.be/OQ5jsbhAv_M?t=3m11s Phil On Wed, Jan 25,

Re: [Pharo-dev] memoized vs once

If one is doing any dynamic programming, the memoization term is pretty natural. https://youtu.be/OQ5jsbhAv_M?t=3m11s Phil On Wed, Jan 25, 2017 at 10:30 PM, Igor Stasenko wrote: > #once can be interpreted as 'evaluate it once', > > but i don't like the #memoized .. it

Re: [Pharo-dev] memoized vs once

All that is nice but I only found about it because I searched for "memoize"... Which is what it does. Phil On Wed, Jan 25, 2017 at 9:29 PM, Nicolas Cellier < nicolas.cellier.aka.n...@gmail.com> wrote: > Hi Eliot, > you should have named the thread "once for all!" > +1 in any case > > 2017-01-25

Re: [Pharo-dev] memoized vs once

Hi, >From my perspective: - I agree with Igor that "once" can be interpreted as "evaluate it only once" as in    "Halt once". - I'm not sure but from the (now very distributed) discussion it is not clear to me if the #once mentioned by Eliot really has exactly the same behavior as

Re: [Pharo-dev] Pharo by Example 50 released!

On 22/01/17 16:53, stepharong wrote: https://pharoweekly.wordpress.com/2017/01/22/pharo-by-example-50-released/ Super special thanks to Nicolai Hess that pushed me to do the last steps to release. Thanks Nicolai your steady commits pushed me! Great. Having an up to date introduction like this

Re: [Pharo-dev] memoized vs once

#once can be interpreted as 'evaluate it once', but i don't like the #memoized .. it sounds painful to my ears. It sounds like something stinking smeared across my face.. and i always got stuck,confused and lost as the meaning of it always escaping my mind, since it naturally defends itself from

Re: [Pharo-dev] Immutability support

2017-01-25 22:24 GMT+01:00 Denis Kudriashov : > For the Process hack, it's because the call-back was designed to return no >> value. > > > Now I am confused. > Why anybody needs to return value from this method? > And why there is "CAN'T REACH" comment at the end of method?

Re: [Pharo-dev] Immutability support

2017-01-25 18:23 GMT+01:00 Clément Bera : > For the Process hack, it's because the call-back was designed to return no > value. Now I am confused. Why anybody needs to return value from this method? And why there is "CAN'T REACH" comment at the end of method? Do you

Re: [Pharo-dev] Pharo by Example 50 released!

This is great news. An up to date PBE is one of the best ways to get people into Pharo. > Sent: Sunday, January 22, 2017 at 10:53 AM > From: stepharong > To: pharo-dev@lists.pharo.org > Cc: pharo-us...@lists.pharo.org > Subject: [Pharo-dev] Pharo by Example 50 released! > >

Re: [Pharo-dev] memoized vs once

Hi Eliot. 2017-01-25 19:56 GMT+01:00 Eliot Miranda : > Hi Ben, > > via FaceBook via twitter I hear you've coined > BlockClosure>>#memoized. Allow me to beg you to rename it to > BlockClosure>>#once. There's a preexisting implementation of this in > VisualWorks by

Re: [Pharo-dev] memoized vs once

Hi Eliot, you should have named the thread "once for all!" +1 in any case 2017-01-25 19:56 GMT+01:00 Eliot Miranda : > Hi Ben, > > via FaceBook via twitter I hear you've coined > BlockClosure>>#memoized. Allow me to beg you to rename it to > BlockClosure>>#once.

Re: [Pharo-dev] Immutability support

yeah, something fishy is happening there. I will take a look. > On 25 Jan 2017, at 18:31, p...@highoctane.be wrote: > > pharo-win-i386-201701151442-c50dec0.zip > > On Wed, Jan 25, 2017 at 3:57 PM, Esteban Lorenzano > wrote: > nevertheless it

Re: [Pharo-dev] Immutability support

On 01/25/2017 03:59 AM, Esteban Lorenzano wrote: > but this is not real immutability, is like a write barrier, that’s why > those method names were not chosen. Thank you for choosing names based on "write barrier," not the incorrect "read-only" or "immutable" (which are just things that can be

[Pharo-dev] memoized vs once

Hi Ben, via FaceBook via twitter I hear you've coined BlockClosure>>#memoized. Allow me to beg you to rename it to BlockClosure>>#once. There's a preexisting implementation of this in VisualWorks by Travis Griggs called once. I hope you agree that it's good to eliminate gratuitous

Re: [Pharo-dev] Immutability support

pharo-win-i386-201701151442-c50dec0.zip On Wed, Jan 25, 2017 at 3:57 PM, Esteban Lorenzano wrote: > nevertheless it should be there in latests vms. > which version are you using? > > Esteban > > On 25 Jan 2017, at 15:04, p...@highoctane.be wrote: > > Tried it and it returns

Re: [Pharo-dev] Immutability support

On Wed, Jan 25, 2017 at 4:42 PM, Denis Kudriashov wrote: > Another question Clement. > > I found that current method doing something strange: > > attemptToAssign: value withIndex: index > process := Processor activeProcess. > [ process suspendedContext: process

Re: [Pharo-dev] [ANN] TechTack today 24/01/2017 16h UTC Bloc/Brick links

2017-01-25 16:34 GMT+01:00 Aliaksei Syrel : > On 25 January 2017 at 16:02, Thierry Goubier > wrote: > >> Yes, it goes a bit faster. But I stopped half way through the list: it is >> tuned a lot slower than I'm used to with Morphic. > > > Hehe :)

Re: [Pharo-dev] Immutability support

Another question Clement. I found that current method doing something strange: attemptToAssign: value withIndex: index process := Processor activeProcess. [ process suspendedContext: process suspendedContext sender ] forkAt: Processor activePriority + 1. Processor yield. "CAN'T REACH" Could

Re: [Pharo-dev] [ANN] TechTack today 24/01/2017 16h UTC Bloc/Brick links

On 25 January 2017 at 16:02, Thierry Goubier wrote: > Yes, it goes a bit faster. But I stopped half way through the list: it is > tuned a lot slower than I'm used to with Morphic. Hehe :) Tuning is another story. Current implementation treats mouse wheel and

Re: [Pharo-dev] Immutability support

2017-01-25 15:52 GMT+01:00 Clément Bera : > Overall, you need to: > - change the code of all numbered primitives mutating objects (such as > at:put:) so that when they fail because of a read-only object they call the > modification tracker framework. > I think it is for

Re: [Pharo-dev] [ANN] TechTack today 24/01/2017 16h UTC Bloc/Brick links

Hi Alex, it's good to see widget development. 2017-01-25 15:40 GMT+01:00 Aliaksei Syrel : > Hi Thierry > > Thanks for your testing effort! > > moz2D prerequisites do not install cleanly on ubuntu 16.04. > > Exactly, it is hard to install many 32 dependencies on 64bit

Re: [Pharo-dev] Immutability support

Norbert, On Wed, Jan 25, 2017 at 3:36 PM, Norbert Hartl wrote: > Clément, > > Am 25.01.2017 um 13:54 schrieb Clément Bera : > > > > On Wed, Jan 25, 2017 at 11:35 AM, Norbert Hartl wro > te: > >> Does anyone know the state of

Re: [Pharo-dev] Immutability support

I am using a quite recent VM that Esteban provides on the JFrog bintray (debug version with symbols). So this is a bit surprising. Phil On Wed, Jan 25, 2017 at 3:41 PM, Clément Bera wrote: > @Phil, then the VM does not support it. I believe the latest VM from >

Re: [Pharo-dev] Immutability support

nevertheless it should be there in latests vms. which version are you using? Esteban > On 25 Jan 2017, at 15:04, p...@highoctane.be wrote: > > Tried it and it returns false for this Windows VM. > > Phil > > On Wed, Jan 25, 2017 at 2:14 PM, Clément Bera

Re: [Pharo-dev] [ANN] TechTack today 24/01/2017 16h UTC Bloc/Brick links

I am using LXC on Ubuntu to build 32 bits libraries without being bothered by the 64 bits side of things. Works nicely, especially since my user home is common to both. See https://gist.github.com/philippeback/33717128d5fb24263e557922d5ac913e Phil On Wed, Jan 25, 2017 at 3:40 PM, Aliaksei Syrel

Re: [Pharo-dev] Immutability support

@Phil, then the VM does not support it. I believe the latest VM from files.pharo.org should support it, but not the stable one. @Denis Sure move it to MirrorPrimitive and update the WriteBarrier tests. On Wed, Jan 25, 2017 at 3:09 PM, Denis Kudriashov wrote: > >

Re: [Pharo-dev] Google summer of code

On Wed, Jan 25, 2017 at 4:44 PM, Thierry Goubier wrote: > Hi guys, > > what I noted from the last attempts is that the Pharo proposal goes like > that: > > - here is a nice list of project ideas > > - newcomers just have to use our current set of tools for interacting

Re: [Pharo-dev] [ANN] TechTack today 24/01/2017 16h UTC Bloc/Brick links

Hi Thierry Thanks for your testing effort! moz2D prerequisites do not install cleanly on ubuntu 16.04. Exactly, it is hard to install many 32 dependencies on 64bit linux system. (there is no solution for this). That is why it would be nice to have 64 bit VM for 64 bit linux :) With 64bit vm

Re: [Pharo-dev] Immutability support

Clément, > Am 25.01.2017 um 13:54 schrieb Clément Bera : > > > > On Wed, Jan 25, 2017 at 11:35 AM, Norbert Hartl > wrote: > Does anyone know the state of immutability support in vm and image? The > latest vm

[Pharo-dev] [pharo-project/pharo-core]

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

[Pharo-dev] [pharo-project/pharo-core] a971e2: 60356

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: a971e21d0feef4294360ce08c630eb1bbdd6416f https://github.com/pharo-project/pharo-core/commit/a971e21d0feef4294360ce08c630eb1bbdd6416f Author: Jenkins Build Server Date:

Re: [Pharo-dev] [ANN] TechTack today 24/01/2017 16h UTC Bloc/Brick links

Hi, Thanks a lot for this! Alex: would you like to take over? :) Cheers, Doru > On Jan 25, 2017, at 3:21 PM, Thierry Goubier > wrote: > > > > 2017-01-25 13:40 GMT+01:00 Denis Kudriashov : > > 2017-01-25 11:45 GMT+01:00 Thierry Goubier

Re: [Pharo-dev] [ANN] TechTack today 24/01/2017 16h UTC Bloc/Brick links

2017-01-25 13:40 GMT+01:00 Denis Kudriashov : > > 2017-01-25 11:45 GMT+01:00 Thierry Goubier : > >> > Nevertheless, it would be very cool to have people test this assumption >>> on old machines. I think Thierry was saying that he has an old machine

Re: [Pharo-dev] Immutability support

2017-01-25 13:59 GMT+01:00 Clément Bera : > It also raise another question: does these primitives support mirror >> approach? (when it can be called with receiver as first argument?) >> > > Yes I made sure the mirror approach works. Even better, there are tests > ensuring

Re: [Pharo-dev] [bloc] addressing the moz2d issue

Hi, Yes, Sparta is independent from Athens. We actually started originally from Athens with a few modifications, but that soon proved to not be feasible because Athens also has to accommodate Morphic while Bloc is being developed. Sparta has a similar structure and intent as Athens, but it

Re: [Pharo-dev] Immutability support

Tried it and it returns false for this Windows VM. Phil On Wed, Jan 25, 2017 at 2:14 PM, Clément Bera wrote: > I introduced the method #supportsWriteBarrier in Pharo 6. > > You can backport it if you want: > > VirtualMachine>>#supportsWriteBarrier > "Answer whether the

Re: [Pharo-dev] Immutability support

I introduced the method #supportsWriteBarrier in Pharo 6. You can backport it if you want: VirtualMachine>>#supportsWriteBarrier "Answer whether the VM observes the per-object read-only flag and consequently aborts writes to inst vars of, and fails primitives that attempt to write, to read-only

Re: [Pharo-dev] Immutability support

On Wed, Jan 25, 2017 at 12:59 PM, Esteban Lorenzano wrote: > but this is not real immutability, is like a write barrier, that’s why > those method names were not chosen. > As Esteban mentioned, read-only objects are not immutable objects, that's why we didn't use these

[Pharo-dev] [pharo-project/pharo-core] 3bb59c: 60355

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 3bb59c064656e99de53bfc9092a643229cee9f68 https://github.com/pharo-project/pharo-core/commit/3bb59c064656e99de53bfc9092a643229cee9f68 Author: Jenkins Build Server Date:

[Pharo-dev] [pharo-project/pharo-core]

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

Re: [Pharo-dev] Immutability support

The "latest" Windows VM I do use has no such method. Virtual Machine --- C:\Users\Philippe\Dropbox\Sibelga\JiraAutomation\Pharo5.0\latestvm\pharo.exe CoInterpreter * VMMaker.oscog-eem.2090 uuid: 63a161b9-17e1-4911-a89a-1687d9ba9a1a Jan 15 2017 StackToRegisterMappingCogit *

Re: [Pharo-dev] Immutability support

Hi again. On Wed, Jan 25, 2017 at 12:04 PM, Denis Kudriashov wrote: > > 2017-01-25 12:03 GMT+01:00 Denis Kudriashov : > >> I think problem that these names could be already in use by frameworks. I >> am sure #isReadOnly, #beReadOnly is used in many

Re: [Pharo-dev] [ANN] TechTack today 24/01/2017 16h UTC Bloc/Brick links

I have got all of the old Pen demos. No big deal to adjust them to Bloc I think. Phil On Wed, Jan 25, 2017 at 12:45 PM, Tudor Girba wrote: > Nice ideas! > > What would be cool if someone else would like to try to implement any of > these. Anyone interested? > > Cheers, >

Re: [Pharo-dev] Immutability support

On Wed, Jan 25, 2017 at 11:55 AM, Denis Kudriashov wrote: > > 2017-01-25 11:47 GMT+01:00 Norbert Hartl : > >> To be honest I think #isReadOnlyObject: is worse :) isXXX is a prefix for >> testing methods. isXXX with an argument feels even more strange. I

Re: [Pharo-dev] Immutability support

On Wed, Jan 25, 2017 at 11:35 AM, Norbert Hartl wrote: > Does anyone know the state of immutability support in vm and image? The > latest vm downloadable is compiled with > > IMMUTABILITY=1 > > (Esteban said that). When I open a pharo6 image with this VM and do: > > ASUser

Re: [Pharo-dev] Immutability support

On 25/01/2017 12:59, Esteban Lorenzano wrote: > but this is not real immutability, is like a write barrier, that’s why > those method names were not chosen. > Then why not #(des)activateWriteBarrier? > Esteban > > -- Cyril Ferlicot http://www.synectique.eu 2 rue Jacques Prévert 01, 59650

Re: [Pharo-dev] [bloc] addressing the moz2d issue

Hi Doru, First, I understand the effort you all made to make this big piece of work. I have however some questions that probably you can help with: 1) I understand Sparta is a library completely independent from Athens. But I also understand that they follow the same reasoning and general design

[Pharo-dev] [pharo-project/pharo-core]

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

[Pharo-dev] [pharo-project/pharo-core] 3b6ae2: 60354

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 3b6ae280bafad0c62a9e3abfb890a8bcc308b9d3 https://github.com/pharo-project/pharo-core/commit/3b6ae280bafad0c62a9e3abfb890a8bcc308b9d3 Author: Jenkins Build Server Date:

Re: [Pharo-dev] [ANN] TechTack today 24/01/2017 16h UTC Bloc/Brick links

2017-01-25 11:45 GMT+01:00 Thierry Goubier : > > Nevertheless, it would be very cool to have people test this assumption >> on old machines. I think Thierry was saying that he has an old machine :). >> @Thierry? >> > >> > I have low-end systems on very recent software

Re: [Pharo-dev] [ANN] TechTack today 24/01/2017 16h UTC Bloc/Brick links

I think that the team should do it and take it as an exercise to document the system. I would also work on a simple application for kids for example with forms (rectangle, star, ) that the kids can duplicate and changed. It could also be a simple application to get satisfactory from customers

Re: [Pharo-dev] Immutability support

but this is not real immutability, is like a write barrier, that’s why those method names were not chosen. Esteban > On 25 Jan 2017, at 12:37, p...@highoctane.be wrote: > > So, beImmutable and beMutable seem pretty usable and not collision causing > IMHO. > > Phil > > On Wed, Jan 25, 2017

Re: [Pharo-dev] [ANN] TechTack today 24/01/2017 16h UTC Bloc/Brick links

Nice ideas! What would be cool if someone else would like to try to implement any of these. Anyone interested? Cheers, Doru > On Jan 25, 2017, at 11:49 AM, Stephane Ducasse > wrote: > > Another example is a logo turtle. > With or without animation. > > Stef > >

[Pharo-dev] [bloc] addressing the moz2d issue

Hi, Thank you for the intensive set of issues you raised during the Bloc presentation. I think it is worthwhile addressing them more thoroughly, so let me start with the issue that seemed to have caused the most worries: Sparta & Moz2D. Please keep in mind that while I am involved to some

Re: [Pharo-dev] Immutability support

So, beImmutable and beMutable seem pretty usable and not collision causing IMHO. Phil On Wed, Jan 25, 2017 at 12:19 PM, Norbert Hartl wrote: > > Am 25.01.2017 um 12:16 schrieb Esteban Lorenzano : > > > On 25 Jan 2017, at 12:04, Denis Kudriashov

Re: [Pharo-dev] Immutability support

Yes, exactly how it felt. Maybe #setImmutable would be more intention revealing. Phil On Wed, Jan 25, 2017 at 11:47 AM, Norbert Hartl wrote: > > Am 25.01.2017 um 11:40 schrieb Denis Kudriashov : > > > 2017-01-25 11:35 GMT+01:00 Norbert Hartl

Re: [Pharo-dev] Immutability support

> Am 25.01.2017 um 12:16 schrieb Esteban Lorenzano : > > >> On 25 Jan 2017, at 12:04, Denis Kudriashov > > wrote: >> >> >> 2017-01-25 12:03 GMT+01:00 Denis Kudriashov >

Re: [Pharo-dev] Immutability support

> On 25 Jan 2017, at 12:04, Denis Kudriashov wrote: > > > 2017-01-25 12:03 GMT+01:00 Denis Kudriashov >: > I think problem that these names could be already in use by frameworks. I am > sure #isReadOnly, #beReadOnly

Re: [Pharo-dev] Immutability support

2017-01-25 12:03 GMT+01:00 Denis Kudriashov : > I think problem that these names could be already in use by frameworks. I > am sure #isReadOnly, #beReadOnly is used in many UI's. For example Margitte > uses it And probably Glorp

Re: [Pharo-dev] Immutability support

2017-01-25 11:59 GMT+01:00 Sven Van Caekenberghe : > why the object suffix, everything is an object, right ? I think problem that these names could be already in use by frameworks. I am sure #isReadOnly, #beReadOnly is used in many UI's. For example Margitte uses it

Re: [Pharo-dev] Immutability support

> On 25 Jan 2017, at 11:55, Denis Kudriashov wrote: > > > 2017-01-25 11:47 GMT+01:00 Norbert Hartl : > To be honest I think #isReadOnlyObject: is worse :) isXXX is a prefix for > testing methods. isXXX with an argument feels even more strange. I would

Re: [Pharo-dev] Immutability support

2017-01-25 11:47 GMT+01:00 Norbert Hartl : > To be honest I think #isReadOnlyObject: is worse :) isXXX is a prefix for > testing methods. isXXX with an argument feels even more strange. I would > rather have #beReadOnly Now there is #beReadOnlyObject and #beWritableObject.

Re: [Pharo-dev] Immutability support

> On 25 Jan 2017, at 11:47, Norbert Hartl wrote: > > >> Am 25.01.2017 um 11:40 schrieb Denis Kudriashov : >> >> >> 2017-01-25 11:35 GMT+01:00 Norbert Hartl : >> ASUser new >> setIsReadOnlyObject: true >> >> And why so

Re: [Pharo-dev] [ANN] TechTack today 24/01/2017 16h UTC Bloc/Brick links

Another example is a logo turtle. With or without animation. Stef On Wed, Jan 25, 2017 at 11:49 AM, Stephane Ducasse wrote: > Doru > > I would like to see the laserGame implemented in Bloc (because it does not > need widgets). > and it will be a real example. > > Stef

Re: [Pharo-dev] [ANN] TechTack today 24/01/2017 16h UTC Bloc/Brick links

Doru I would like to see the laserGame implemented in Bloc (because it does not need widgets). and it will be a real example. Stef On Wed, Jan 25, 2017 at 11:45 AM, Thierry Goubier wrote: > > > 2017-01-25 11:33 GMT+01:00 Tudor Girba : > >> Hi,

Re: [Pharo-dev] Immutability support

> Am 25.01.2017 um 11:40 schrieb Denis Kudriashov : > > > 2017-01-25 11:35 GMT+01:00 Norbert Hartl >: > ASUser new > setIsReadOnlyObject: true > > And why so ugly name? Why not #isReadOnlyObject:? To be honest I

Re: [Pharo-dev] [ANN] TechTack today 24/01/2017 16h UTC Bloc/Brick links

2017-01-25 11:33 GMT+01:00 Tudor Girba : > Hi, > > > On Jan 25, 2017, at 11:19 AM, Thierry Goubier > wrote: > > > > Hi Doru, > > > > 2017-01-25 10:22 GMT+01:00 Tudor Girba : > > ... > > > > Nevertheless, it would be very cool

Re: [Pharo-dev] Immutability support

2017-01-25 11:35 GMT+01:00 Norbert Hartl : > ASUser new > setIsReadOnlyObject: true > And why so ugly name? Why not #isReadOnlyObject:?

[Pharo-dev] Immutability support

Does anyone know the state of immutability support in vm and image? The latest vm downloadable is compiled with IMMUTABILITY=1 (Esteban said that). When I open a pharo6 image with this VM and do: ASUser new setIsReadOnlyObject: true; name: 'foo' with ASUser>>#name: arg1

Re: [Pharo-dev] [ANN] TechTack today 24/01/2017 16h UTC Bloc/Brick links

Hi, > On Jan 25, 2017, at 11:19 AM, Thierry Goubier > wrote: > > Hi Doru, > > 2017-01-25 10:22 GMT+01:00 Tudor Girba : > ... > > Nevertheless, it would be very cool to have people test this assumption on > old machines. I think Thierry was

Re: [Pharo-dev] [ANN] TechTack today 24/01/2017 16h UTC Bloc/Brick links

Hi Doru, 2017-01-25 10:22 GMT+01:00 Tudor Girba : > ... > > Nevertheless, it would be very cool to have people test this assumption on > old machines. I think Thierry was saying that he has an old machine :). > @Thierry? > I have low-end systems on very recent software

Re: [Pharo-dev] CALL for GSoC project proposals

But I understand the process. So I did a pass On Wed, Jan 25, 2017 at 11:05 AM, Stephane Ducasse wrote: > Hi yuriy > > you could have done it a bit less brutal. > > Stef > > On Wed, Jan 25, 2017 at 10:52 AM, Yuriy Tymchuk > wrote: > >> Dear all,

Re: [Pharo-dev] CALL for GSoC project proposals

Hi yuriy you could have done it a bit less brutal. Stef On Wed, Jan 25, 2017 at 10:52 AM, Yuriy Tymchuk wrote: > Dear all, this year we plan to apply again as a mentoring organization for > Google Summer of Code. However, we are going to follow a different strategy >

[Pharo-dev] CALL for GSoC project proposals

Dear all, this year we plan to apply again as a mentoring organization for Google Summer of Code. However, we are going to follow a different strategy regarding project proposals. Instead of having a swarm of small ideas we want to end up with around ten well-described projects. This is why I

Re: [Pharo-dev] Google summer of code

On Wed, Jan 25, 2017 at 7:38 AM, Stephan Eggermont wrote: > On 24/01/17 10:11, Guillermo Polito wrote: >> >> Besides, I'm interested in knowing the official reasons for why we were >> rejected last years :P. > > > That's the always the same: we get many more applications than we

Re: [Pharo-dev] [ANN] TechTack today 24/01/2017 16h UTC Bloc/Brick links

Hi Stef, Thanks for these questions. See some replies inline and we will also create threads with the larger topics to get people more engaged. > On Jan 25, 2017, at 9:32 AM, Stephane Ducasse wrote: > > Hi bloc/brick guys > > I was a great talk. I had to run because

Re: [Pharo-dev] Google summer of code

Hi guys, what I noted from the last attempts is that the Pharo proposal goes like that: - here is a nice list of project ideas - newcomers just have to use our current set of tools for interacting and producing code (that is slack / mailing list / smalltalkhub / github / fogbugz / medium /

Re: [Pharo-dev] [ANN] TechTack today 24/01/2017 16h UTC Bloc/Brick links

Hi bloc/brick guys I was a great talk. I had to run because I forgot my appointment to the doctor. Now some points - first a meta point: we should check how we can get more people following the talks. Now related to bloc/bricks - we should pay really attention to the maintenance and deployment

Re: [Pharo-dev] Google summer of code

Yuriy I cleaned many of the proposal could you do a pass on yours and keep max 4-5 of them? On Mon, Jan 23, 2017 at 5:15 PM, Yuriy Tymchuk wrote: > I can also update my projects and help with the application if needed (I > was a part of the application team for the last