- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] WhatsUp from: 2013-08-05 until: 2013-08-18

by Erwan Douaille

2013/8/5 <seaside(a)rmod.lille.inria.fr> > Hi! We're sending this automatic email twice a month, to give the > community an opportunity to easily know what's happening and to coordinate > efforts. Just answer informally, and feel free to spawn discussions > thereafter! > > ### Here's what I've been up to since the last WhatsUp: > > GSOC try to fix bugs (Thanks Esteban :) GSOC evaluation GSOC spec code generation, i made a video. You can watch it there : http://uipainter-gsoc.over-blog.com/ > > ### What's next, until 2013-08-18 (*): > - GSOC spec code generation, the past one is really "stupid". I have to parse the morph and know exactly where my submorphs are and which layout i have to use to setup the final render. -- Best regards, Douaille Erwan <douaille.erwan(a)gmail.com>

Aug. 5, 2013

Re: [Pharo-dev] Smalltalk = strongly typed

by Igor Stasenko

On 3 August 2013 20:53, kilon <thekilon(a)yahoo.co.uk> wrote: > btc wrote >> btc@ > >> wrote: >> >> Kilon, I agree with most of you writeup, except that I think Smalltalk >> has types - except the types are not associated with variables, rather >> they are associated with objects. This aligns with Igor's comment "in >> smalltalk, assignment is not copying value, but changing the reference". > > Actually I also mostly agree with Igor point. If I am not mistake we agree > on the fact that smalltalk has no types. > > The only thing I would not agree, if my assumption is correct here, is that > Igor appears here implying that smalltalk somehow is special to assign > values by reference. If this assumption of mine is correct then I do > disagree strongly , its actually a very common practice. Python also > implement this, Lisp does, ruby and an array of dynamic type languages. I am > not so sure about C and C++ but since they use pointers its a moot point > anyway. > > I explain this concept in my book about python that I have published in > blenderwiki , section "Reference" which can be found here -> > http://wiki.blender.org/index.php/User:Kilon/Python_book_of_magic/05.Dictio… > Sure, i didn't meant that this is unique to smalltalk. > However this concept is implementation specific and not language specific. > Its obviously a massive diffirence because a coder rarely worries about the > implementation itself the same way a user of an OS does not worry how and > why an OS does the things it does, he only care about what it does. > Well, a language should define how assignment works, so it can be implemented. And apparently assignment by copying value won't fit for smalltalk. > Also I am not sure how that prove the existence of types, for me it does > not, it only describes how values are assigned. What prevents you from > assigning by reference typeless data ? > > Unless once again we talk about how pharo itself implement this and somehow > uses its own internal type system. The question that remain why I the coder > should care about this , if at language level Smalltalk is typeless. > > Maybe Igor can clarify this more to make a more clear picture what happens > at implementation level. But at language level yes I have seen nothing that > proves the existence of types inside Smalltalk unless we treat types in a > very vague kind way which for me it just defeats their purpose. > I think that too.. To me it looks like an attempt to describe the world with favorite tool - thermometer. > I also agree on the remark of Duck Typing , it definitely smells like > smalltalk , but once again the terminology is failed because it implies a > type system. > > Once more I have to stress the importance of dichotomy between language > specification and language implementation. Types obviously touch both areas > but not necessarily for same reasons. > > > > > > -- > View this message in context: http://forum.world.st/Smalltalk-strongly-typed-tp4701894p4702028.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > -- Best regards, Igor Stasenko.

Aug. 5, 2013

WhatsUp from: 2013-08-05 until: 2013-08-18

by seaside＠rmod.lille.inria.fr

Hi! We're sending this automatic email twice a month, to give the community an opportunity to easily know what's happening and to coordinate efforts. Just answer informally, and feel free to spawn discussions thereafter! ### Here's what I've been up to since the last WhatsUp: - $HEROIC_ACHIEVEMENTS_OR_DISMAL_FAILURES_OR_SIMPLE_BORING_NECESSARY_TASKS ### What's next, until 2013-08-18 (*): - $NEXT_STEPS_TOWARDS_WORLD_DOMINATION (*) we'll be expecting results by then ;)

Aug. 5, 2013

Did canUnderstand: changed?

by StÃ©phane Ducasse

Hi why canUnderstand: now handles shouldNotImplement? Stef

Aug. 4, 2013

Re: [Pharo-dev] is there anyone who can use SimpleMIDIPort on Mac OSX 10.6.8?

by laurent laffont

Hi, I was looking about MIDI on Linux today, and may be that's related. On Linux, for the MIDI plugin, there's 2 files: - sqUnixMIDIALSA.inc - sqUnixMIDINone.inc it seems sqUnixMIDINone is build, and not ALSA one. In /platforms/unix/plugins/MIDIPlugin/sqUnixMIDI.c: #if defined(USE_MIDI_ALSA) # include "sqUnixMIDIALSA.inc" #else # include "sqUnixMIDINone.inc" #endif USE_MIDI_ALSA is set in a configure script, and if I understand correctly, it is not used with the cmake process ? Anyway, I've changed to: #include "sqUnixMIDIALSA.inc" and the file compile, but fail to link. It seems gcc doesn't have the needed -l flag to link to alsa lib, but I don't know where to specify this (I suppose somewhere in VMMaker ?) Cheers, Laurent On Sun, Aug 4, 2013 at 5:09 PM, NISHIHARA Satoshi <goonsh(a)gmail.com> wrote: > is there anyone who can use SimpleMIDIPort on Mac OSX 10.6.8? > > StÃ©phane Ducasse san told me that it can use MIDIPlugin in Pharo 2.0 > on Mac 10.8.3. > but I can't use MIDIPlugin on Mac OSX 10.6.8. > > SimpleMIDIPort>>#midiIsSupported > -> false > SimpleMIDIPort>>#primPortCount > -> 0 > > vm: > Pharo.app(13/03/13) > Pharo-126.app(13/05/04) > Pharo-145.app(13/05/31) > Pharo-169.app(13/07/10) > Pharo-186.app(13/07/15) > Pharo-187.app(13/07/19) > Pharo-188.app(13/07/31) > > I would like to know whether it is a problem of all those that are > using 10.6.8 or personal trouble. > > -p.s.- > > On Eliot Miranda san's CogMT.r2761.app and Cog.r2761.app, > SimpleMIDIPort>>#midiIsSupported > -> true > SimpleMIDIPort>>#primPortCount > -> 1 > > regards. > >

Aug. 4, 2013

Re: [Pharo-dev] Announcer problem :)

by StÃ©phane Ducasse

The real problem is that the error that was raised on on:do: was removed and now... NewValueHolder>>whenChangedDo: aBlock | block | block := [:announcement :ann | aBlock cull: announcement newContents cull: announcement oldContents cull: announcement cull: ann ]. announcer weak on: ValueChanged do: block Now may be it is not a problem and a strong reference is ok too. We will have to analyse that. Stef > So igor is thinking about ephemerons and object formats. > Because we are going over all the weak on:do: and rewriting the ones we can. > > > whenListChanged: aBlock > "Specify a block to value after the contents of the list has changed" > > "Basically when you set a new list of items" > > <api: #event> > | block | > block := [ :announcement :ann | > aBlock > cull: announcement newContents > cull: announcement oldContents > cull: announcement > cull: ann ]. > listAnnouncer weak > on: ValueChanged > do: block > > > On Aug 4, 2013, at 4:16 PM, StÃ©phane Ducasse <Stephane.Ducasse(a)inria.fr> wrote: > >> addDependent: anObject >> >> self announcer >> on: MorphChanged >> do: [ :ann | anObject update: ann selector ]. >> >> self announcer >> on: MorphChangedWithArguments >> do: [ :ann | anObject update: ann selector with: ann arguments ]. >> >> ^ anObject >> >> is an example of the problem because addDependent: was holding also weakly its dependent and now >> we cannot use weak with blocks. >> >> Stef > >

Aug. 4, 2013

Re: [Pharo-dev] is there anyone who can use SimpleMIDIPort on Mac OSX 10.6.8?

by StÃ©phane Ducasse

to test please load Gofer new smalltalkhubUser: 'PharoExtras' project: 'Sound'; package: 'ConfigurationOfPharoSound'; load. ((Smalltalk globals at: #ConfigurationOfPharoSound) project version: '5.3') load

Aug. 4, 2013

Re: [Pharo-dev] Announcer problem :)

by StÃ©phane Ducasse

So igor is thinking about ephemerons and object formats. Because we are going over all the weak on:do: and rewriting the ones we can. whenListChanged: aBlock "Specify a block to value after the contents of the list has changed" "Basically when you set a new list of items" <api: #event> | block | block := [ :announcement :ann | aBlock cull: announcement newContents cull: announcement oldContents cull: announcement cull: ann ]. listAnnouncer weak on: ValueChanged do: block On Aug 4, 2013, at 4:16 PM, StÃ©phane Ducasse <Stephane.Ducasse(a)inria.fr> wrote: > addDependent: anObject > > self announcer > on: MorphChanged > do: [ :ann | anObject update: ann selector ]. > > self announcer > on: MorphChangedWithArguments > do: [ :ann | anObject update: ann selector with: ann arguments ]. > > ^ anObject > > is an example of the problem because addDependent: was holding also weakly its dependent and now > we cannot use weak with blocks. > > Stef

Aug. 4, 2013

is there anyone who can use SimpleMIDIPort on Mac OSX 10.6.8?

by NISHIHARA Satoshi

is there anyone who can use SimpleMIDIPort on Mac OSX 10.6.8? StÃ©phane Ducasse san told me that it can use MIDIPlugin in Pharo 2.0 on Mac 10.8.3. but I can't use MIDIPlugin on Mac OSX 10.6.8. SimpleMIDIPort>>#midiIsSupported -> false SimpleMIDIPort>>#primPortCount -> 0 vm: Pharo.app(13/03/13) Pharo-126.app(13/05/04) Pharo-145.app(13/05/31) Pharo-169.app(13/07/10) Pharo-186.app(13/07/15) Pharo-187.app(13/07/19) Pharo-188.app(13/07/31) I would like to know whether it is a problem of all those that are using 10.6.8 or personal trouble. -p.s.- On Eliot Miranda san's CogMT.r2761.app and Cog.r2761.app, SimpleMIDIPort>>#midiIsSupported -> true SimpleMIDIPort>>#primPortCount -> 1 regards.

Aug. 4, 2013

Re: [Pharo-dev] [Pharo-fuel] Fuel API bug

by StÃ©phane Ducasse

impressive :) Tx guys. We are fighting with memory leaks like mad :) Stef On Aug 4, 2013, at 4:49 PM, Max Leske <maxleske(a)gmail.com> wrote: > Done. > > Name: ConfigurationOfFuel-MaxLeske.207 > Author: MaxLeske > Time: 4 August 2013, 4:49:17.037 pm > UUID: 5cc59075-e365-4a58-a20b-22e40b2b70c9 > Ancestors: ConfigurationOfFuel-MartinDias.206 > > * created new version 1.9.2 for development > * pointed development to 1.9.2 > * includes changes Camillo wanted to introduce into 1.9.1 (DateAndTime fix) > > > On 04.08.2013, at 16:35, Max Leske <maxleske(a)gmail.com> wrote: > >> Yeah, no problem. I'll get on it right away. >> >> Max >> >> On 04.08.2013, at 16:10, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> >>> Hi guys >>> >>> can you rename this method? >>> >>> on: aCollectionOrStream do: aBlock >>> "Evaluates a block with a new stream based on the collection or stream. Answers the result of the block evaluation. Follows the style of FileStream>>fileNamed:do:." >>> | aStream | >>> aStream := self on: aCollectionOrStream. >>> [ ^ aBlock value: aStream ] ensure: [ aStream close ] >>> >>> >>> Please do not use on:do: for something that is not about exception (and announcements). >>> >>> It is too confusing and refactor after. >>> >>> Stef >> > > > _______________________________________________ > Pharo-fuel mailing list > Pharo-fuel(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel

Aug. 4, 2013