Hi,
Good news: the job is not constraint by the “2 years after university”
condition, but instead it is a
so called “Experienced Engineer” position:
http://www.inria.fr/en/institute/recruitment/offers/find-a-position?nPostingId=9624&nPostingTargetId=15693&id=PNGFK026203F3VBQB6G68LOE1&l
Excerpts from Marcus Denker's message of 2015-05-29 10:17:24 +0200:
> Hi,
>
> Good news: the job is not constraint by the “2 years after university”
> condition, but instead it is a
> so called “Experienced Engineer” position:
>
>
> http://www.inria.fr/en/institute/recruitment/offers/find-
> On 29 May 2015, at 10:28, Martin Bähr
> wrote:
>
> Excerpts from Marcus Denker's message of 2015-05-29 10:17:24 +0200:
>> Hi,
>>
>> Good news: the job is not constraint by the “2 years after university”
>> condition, but instead it is a
>> so called “Experienced Engineer” position:
>>
>>
Also implied, but seldom stated, is that all values used in = and hash must
only be set at creation, never after.
The reason is the same, keeping hashed collection usage sane;
p := Point x: 3 y: 2.
Set add: p.
"Imaginary method"
p setX: 2.
Set includes: p -> false
Cheers,
Henry
> On 26 May 2015,
Hello all
Thanks for the comments. I should have made myself clearer in my second post
(moral: don’t post after midnight!). The original query related to a simple
case, which I had solved, but which alerted me to the problem of incompatible
versions in Fuel. The next stage of my work (still
Sure, next time it happens, I will do it.
Thanks,
Juraj
> On May 29, 2015, at 03:23, Marcus Denker wrote:
>
> Can you send my an image saved in that state?
>
>> On 28 May 2015, at 17:27, Juraj Kubelka wrote:
>>
>> Hi,
>>
>> regularly I cannot debug methods because nil does not understand
Wow, compelling example!
Alexandre
> On May 29, 2015, at 12:33 PM, Henrik Johansen
> wrote:
>
> Also implied, but seldom stated, is that all values used in = and hash must
> only be set at creation, never after.
> The reason is the same, keeping hashed collection usage sane;
> p := Point x:
Is it okay that the Playground's inspector drills down on the self
variable indefinitely?
It is... #(1 2 3) "Do it and go" will result in an Array being
inspected, if I click on "self" it will open a new inspector on the
side on the same object, and this can as deep as you want.
I would block tha
Hi,
Indeed, this part of the inspector will be revisited for Pharo 5.
But, what exactly do you mean by " I just want to select it to run an
expression where self refers to the inspected object"?
Cheers,
Doru
On Fri, May 29, 2015 at 5:30 PM, Esteban A. Maringolo
wrote:
> Is it okay that the
2015-05-29 12:36 GMT-03:00 Tudor Girba :
> Hi,
>
> Indeed, this part of the inspector will be revisited for Pharo 5.
Good. I'm sure this can be backported easily ;)
> But, what exactly do you mean by " I just want to select it to run an
> expression where self refers to the inspected object"?
I
Also... I find myself accidentally closing the whole Playground in an
attempt to just close the inspector.
I know this is related with me not being the smartest guy in the
block, but I'm so used to discard inspectors, and when you're somehow
deep inspecting you completely forgot you started in a "
> On 19 May 2015, at 11:01 , Sven Van Caekenberghe wrote:
>
>
>> On 19 May 2015, at 10:53, Udo Schneider wrote:
>>
>>> Did you look in all your package caches ?
>> I did. Must have been a victim of cleaning ... but maybe TimeMachine has
>> something ... thanks for the reminder.
>>
>>> If it
> On 29 May 2015, at 18:23, Henrik Johansen
> wrote:
>
>>
>> On 19 May 2015, at 11:01 , Sven Van Caekenberghe wrote:
>>
>>
>>> On 19 May 2015, at 10:53, Udo Schneider
>>> wrote:
>>>
Did you look in all your package caches ?
>>> I did. Must have been a victim of cleaning ... but mayb
Hi Esteban,
On Fri, May 29, 2015 at 5:42 PM, Esteban A. Maringolo
wrote:
> 2015-05-29 12:36 GMT-03:00 Tudor Girba :
> > Hi,
> >
> > Indeed, this part of the inspector will be revisited for Pharo 5.
>
> Good. I'm sure this can be backported easily ;)
It won't because this will be a new impl
Hi,
Indeed, this is a usability issue.
However, your code is not lost. You can find the playground easily, and if
you inspect the same objects, the raw presentation will show you the last
entered code for each class.
Cheers,
Doru
On Fri, May 29, 2015 at 6:15 PM, Esteban A. Maringolo
wrote:
Sven Van Caekenberghe-2 wrote
> I am sure you will blog about this !
Yes, pleeease!!
-
Cheers,
Sean
--
View this message in context:
http://forum.world.st/Issue-with-UDP-Sockets-tp4827014p4829352.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Hi,
I'm trying to load the Reddit example from SmalltalkHub (Monticello), it
fails with:
This package depends on the following classes:
DescriptorSystem
You must resolve these dependencies before you will be able to load these
definitions:
RedditSchema
allTableNames
classModelForRedditLin
On Sat, May 30, 2015 at 12:15 AM, Esteban A. Maringolo
wrote:
> Also... I find myself accidentally closing the whole Playground in an
> attempt to just close the inspector.
>
> I know this is related with me not being the smartest guy in the
> block, but I'm so used to discard inspectors, and when
On Sat, May 30, 2015 at 12:23 AM, Henrik Johansen
wrote:
> P.S. On the plus side, I'm now able to turn my PC into a better remote for
> multi-cam GoPro setups than the GoPro remote itself is :)
That is cool to hear. Now as much as frameworks are important, I
think cool little end-user apps like
19 matches
Mail list logo
