Pharo-dev
By thread
pharo-dev@lists.pharo.org
By month
Messages by month
- ----- 2026 -----
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2025 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2024 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2023 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2022 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2021 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2020 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2019 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2018 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2017 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2016 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2015 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2014 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2013 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2012 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2011 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2010 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2009 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2008 -----
- December
- November
- October
- September
- August
- July
- June
- May
August 2009
- 77 participants
- 1342 messages
Re: [Pharo-project] Create a changeset for an entire package?
by Michael Roberts
Monticello ?
Mike
On Friday, August 14, 2009, Javier Pimás <elpochodelagente(a)gmail.com> wrote:
> It seems fixing bugs is not the only hard part... I've a bunch of fixes for GLCanvas, and a small proposed change for the class browser but I can't find a way to export a diff of all the changed packages, nor a diff of an entire package nor a diff of a class so anybody can see the changes before commiting... Do I have to file out every class I changed? there has to some easier way.
>
> Thanks,
> Â Â Â Â Â Â Â Â Â Â Javier.
> --
> Javier Pimás
> Ciudad de Buenos Aires
>
Aug. 16, 2009
Re: [Pharo-project] Complex number support discussion
by Igor Stasenko
2009/8/16 <csrabak(a)bol.com.br>:
> Em 15/08/2009 19:21, Igor Stasenko < siguctua(a)gmail.com > escreveu:
>
>> 2009/8/16 <csrabak(a)bol.com.br>:
>> > Your first example is interesting. Â It boils down to two design aspects:
>> >
>> > If you need Complex numbers in the same application, you need to refactor
>> > the code to:
>> >
>>
>> > length := (something positive) ifTrue:[something sqrt ]
>> > IfFalse: Error do: [ 5 ].
>>
>> i'm sure you meant
>> length := (something positive) ifTrue:[something sqrt ] IfFalse: [ 5 ]
>
> I'm not so sure ;-) I thought your block with a five inside some kind of error message, but this is not that important. It seems you get the spirit and considering my mistake on interpreting your example your correction is OK.
>
>>
>> but then
>> #positive is a test which defined as
>>
>> positive
>> ^ self > 0
>>
>> and we getting back to discussion , what is the meaning of #> or #<
>> operator for complex values.
>>
> NO!! Because all this discussion is being on the possibility of having an operation on a _non_ Complex number return a Complex result, so the test is kosher and you can go. _If_ you return an argument that something already was a complex number then all this argument is moot...
Let me restate where we started from. We started from point:
Array new: 0.2i
which simply shown that there are many places where complex numbers
appearance (or even non-integer numbers) is undesirable.
But since you insisting on introducing the functions which do implicit
conversions under the hood, without real intent of developer, how he
could be sure that above not happens?
And then same, in next example:
(something positive) ifTrue:[something sqrt ] IfFalse: [ 5 ]
how you can be sure that 'something' is not complex number already,
and therefore, sending #positive to it is meaningless?
>
> [snipped]
>
>> > Once you put Complex in the Smalltalk paradigm, I think we should preserve
>> > as much as possible this design decision made at the start of the language.
>> > From a programming POV -4 sqrt mapping from Real to Imaginary (Complex) is
>> > homologous to 13 / 3 giving a Fraction. Â Overall is a modeling of the world.
>> >
>> > BTW, this is why I think having Complex to only have Float members is not a
>> > nice design decision...
>> >
>> ageed. Its can hold any values representing the value from a Real set.
>> But as soon as one of its member start holding someting different
>> (Complex) - you are in trouble.
>
> It depends. Â My reasoning was that if we maintain the members as two numbers in Smalltalk sense and let the mechanisms choose the representation (actually the classes), a lot of possible problems with Complex numbers not coalescing back to real due non canceling of imaginary parts (due rounding errors) could be minimized.
>
> This could make Pharo Smalltalk more interesting than using other languages where all the problems with numerical accuracy have to be taken in account.
>
Rounding errors plaguing the Real numbers in the same way, and i don't
see much difference here.
Where i see the difference is, that for real numbers you need to
represent a single value (and no matter by what you representing it -
because it is still Real value),
while for complex number you need a two distinct values (but they
could be represented by any real values you desire).
But since you don't see such difference and advocating that complex is
just a 'more generic' representation of real, an no-one should care
where it seamlessly appears and when (because of implicit coercions),
then give me the answer, where you want to stop:
1. Two different ways representing real value:
1/2 <=> 0.5
2. Two different ways representing ?same? value:
0.5 <=> 0.5 + 0i
3. Three different ways representing ?same? value:
0.5 <=> 0.5 + 0i <=> Complex real: (0.5 + 0i) imaginary: (0 + 0i)
4. Four different ways representing ?same? value:
0.5 <=> 0.5 + 0i <=> Complex real: (0.5 + 0i) imaginary: (0 + 0i)
<=> Complex real: (0.5 + (Complex real: 0+ 0i imaginary: 0 + 0i))
imaginary: (0 + 0i)
and so on...
>>
>> I simply wanted to illustrate you that passing values to code which
>> not expecting the Complex values
>> having same side effect as passing a Complex values to members of
>> Complex value (real/imaginary) part, and state that its ok.
>
> I'm sorry to inform you that until now you have not achieved your intent in showing me a robust case. . .
>
>>
>> That's why its is good to have separation from functions which
>> operating with reals only and can NEVER return anything else than real
>> values from functions which can return complex values.
>
> I maintain my opinion that this is not helpful to make Pharo (having an implementation like this) compelling for doing work with this kind of programming. Â For doing this way you rather do it in a spreadsheet application that has for any function a separate one for complex numbers: it works, but is cumbersome and makes code become bulkier.
>
> A strength of OO languages is polymorphism and Smalltalk adds to it dynamic typing.
>
How polymorphism helps in making two different functions (one which
producing an error on negative argument, while another producing a
complex value) to be identified by a single message selector for a
single class?
> The separation you advocate make these advantages be lost.
>
> --
> Cesar Rabak
>
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project(a)lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
--
Best regards,
Igor Stasenko AKA sig.
Aug. 16, 2009
Re: [Pharo-project] Create a changeset for an entire package?
by Lukas Renggli
>> a) I don't wan't to include everything I changed from the package.
>> There are some things that I changed for debugging. So, I can't
>> fileout everything and I don't know if monticello will let me do
>> what I want.
>
> so far you cannot in MC
It is possible, but it requires some manual work to get a custom
change-set from A to B:
1. Make sure that both versions A and B are stored as Monticello
Packages (probably to a local directory).
2. Load version A.
3. Load version B.
4. In the changes-browser there is now a new change-set named A->B.
5. Open a change browser on it and edit it as you like.
6. File-out the change-set.
What I usually do is different and I think goes better with the whole
workflow of Monticello:
1. In an image where I have the modified code I display the changes
between the previous version (A) and the current image (B).
2. Then I selectively revert the changes that I don't want to go into B.
3. And commit the package B.
>> b) Supose the change includes 3 separate packages, that should be
>> seen as a one. Loading only one package only would break things, so
>> I'd like the change to include all 3 in one operation.
It is possible to create custom PackageInfo subclasses (Seaside <= 2.8
did this), but I have rarely seen this and don't find it particularly
useful. I would stick to the original packages to make merging for the
maintainers easy.
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
Aug. 16, 2009
Re: [Pharo-project] Analog to Dolphin's #forkMainIfMain?
by Stéphane Ducasse
Bill (and igor)
I would love to continue to remove Project from the image so the
"spawnProcessIfThisIsUI:self activeProcess."
should probably find another host. Do you have an idea about the class
that could be the natural place to define
such a method?
if so can you propose a change?
Stef
On Aug 16, 2009, at 5:57 AM, Schwab,Wilhelm K wrote:
> Sig, all,
>
> I have been preparing MC packages with classes and method designed
> to soften the blow of moving much of my domain code to Pharo. In
> this case, I have some sends of ProcessorSchedler>>forkMainIfMain,
> so I created that method. Initially, I made it emtpy, and then
> based on what you helpe me find, I tried
>
> ProcessorScheduler>>forkMainIfMain
> Project spawnProcessIfThisIsUI:self activeProcess.
>
>
> The above gets called from something that then immediately waits on
> a semaphore that is signalled by one of two threads. One of the
> threads waits on a timer, the other tries to evaluate a block;
> creating a background worker thread that will run for a limited
> time. There is a test case that tries various combinations, some of
> which should succeed and some should time out. I have used these
> things in production in Dolphin for some time.
>
> In Dolphin, #forkMainIfMain allows the UI to be responsive during
> these tests, but trying the above in Pharo turns ugly. There are
> problems that appear to related to two UI processes - running short
> of events or something like that. The tests run for only a few
> seconds, though I suppose I could try to allow enough time to look
> around, but then I'm probably not the right person to do the looking
> anyway.
>
> DUMB question: the argument to #spawnProcessIfThisIsUI: is named
> suspendedProcess. Do I need to ensure the process in question is
> indeed suspended before entering the method? If so, then I start
> wondering how to get there from #forkMainIfMain, but it's a little
> late for my brain to take on that question.
>
> One thing is certain: what I tried did not work. There were errors
> from the event loop and even some screen scarring.
>
> Bill
>
>
> -----Original Message-----
> From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr
> ] On Behalf Of Igor Stasenko
> Sent: Saturday, August 15, 2009 3:29 PM
> To: Pharo-project(a)lists.gforge.inria.fr
> Subject: Re: [Pharo-project] Analog to Dolphin's #forkMainIfMain?
>
> 2009/8/15 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>:
>> Is there anything in Pharo that starts a new main thread to carry
>> on for one that is about to get blocked? It might be that Pharo
>> does not need it, since sockets are serviced by the VM, where
>> Dolphin (at least prior to overlapped calls) did the I/O through
>> the event loop; if the main thread stopped, so did Windows event
>> dispatching, and hence no socket I/O.
>>
> There is such thing.
> Try to explore the way how debugger handling this (when process you
> want to debug is current UI process), or when you pressing interrupt
> key.
>
> See Debugger>>openOn: process context: context label: title contents:
> contentsStringOrNil fullView: bool
>
> at 'Project spawnNewProcessIfThisIsUI: process'
>
>
>
>> Dolphin to some extent, and WindowBuilder to (IIRC) a large extent
>> create modal loops in Smalltalk code. I see a few references to
>> such things in Pharo, but I'm fairly lost. Where should I start
>> reading and/or browsing?
>>
>> Bill
>>
>>
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> Pharo-project(a)lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project(a)lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> _______________________________________________
> Pharo-project mailing list
> Pharo-project(a)lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Aug. 16, 2009
Re: [Pharo-project] [update] 10414
by Stéphane Ducasse
>>
>> If you execute in a Pharo-core image:
>>
>> ScriptLoader new cleanUpForProduction; cleanUpForRelease
>>
>> you get an image without tests and SUnit that is 8.0 MB on disk.
>>
>
> And after deleting the ScriptLoader class, it's only 6.9 MB.
Interesting how strings can take space :)
But we will delete only for the 1.0 for the 1.1alpha I need the
history :)
at least for now :)
Aug. 16, 2009
Re: [Pharo-project] Spelling error in method name
by Stéphane Ducasse
yes
add a bug entry
On Aug 16, 2009, at 12:08 AM, csrabak(a)bol.com.br wrote:
> I think the method RangeConstraint>>isPositveValid shoud be
> RangeConstraint>>isPositiveValid, shouldn't it?
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project(a)lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Aug. 16, 2009
Re: [Pharo-project] ORM for Pharo -- ½ OFF
by Stéphane Ducasse
+1
On Aug 15, 2009, at 1:42 AM, Mariano Martinez Peck wrote:
>
>
> 2009/8/14 <csrabak(a)bol.com.br>
>
> Mariano,
>
> I agree (and I myself have been on the Research side getting answers
> similar to those ones) in fact I'll add another item to your list:
>
> -- They have an "architectural steering committee" that dictates use
> of some RDBS
>
> I've seen this even requiring some ERP used different database
> engine thas suggested by supplier. . .
>
> So if we want to compete with enterprise applications we need to get
> into some Enterprise:
>
> We're still thinkering with printing in Pharo (and this is PITA when
> attempting to be platform agnostic), so no Report Generator still,
> no matter how well you connect to a RDBS, any slightly above trivial
> example CRUD application will need this support.
>
> Our present set of widgets is sleek but still not as comprehensive
> as the other competing approaches, and we still have not created
> enough baseline to have an "echo system" so third parties can
> augment them as it happens now with Java, .Net and happened (and
> still as legacy updates) in Delphi and VB.
>
> So if the goal is to reach those enterprise trench we have to find
> some company that would profit of having [Pharo] Smalltalk as a
> primary language to customize or augment their system, as today (say
> as sake of example, SAP has ABAP but with Netweaver is going Java,
> and they competitors similar path).
>
> Let's think about this: historically some (comercial) Smalltalks
> allowed via OLE (a.k.a. COM, etc.) to access Microsoft Office
> features and do things similar as VB (in fact even Tcl and Python
> allow that), but what is the "productivity" of programmer that finds
> a tutorial or an example in VB and has to "translate" it to Smalltalk?
>
> As today can we enumerate what would be an advantage of doing
> something in Pharo instead of some "mainstream" language just to do
> some GUI painting CRUD application?
>
> I don't know if I understand you. The idea and goal behind Pharo is
> to have the open, free, clean and robust smalltalk that we were
> missing for years for commercial applications. At least that's my
> idea of Pharo. It must be a platform and a base where you can create
> tools in it and with both of them create real applications.
>
> In my opinion Pharo shouldn't be associated with a particular UI
> (web or desktop) neither to a persistence strategy. Pharo must be
> the base of all that. So then you can have differents alternatives:
> For UI's you can have PolyMorph and the UI Builder. For Web you can
> have Seaside and Aida/Web. But pharo is not coupled with any of
> them. You will then choose the solutions that best feets your needs.
>
> In summary, I would love to use Pharo as platform to build
> enterprise and commercial applications. No matter how do I persist
> or display my objects.
>
> Best,
>
> Mariano
>
>
>
>
> again my 0.01999....
>
> Regards,
>
> --
>
> Cesar Rabak
>
>
> Em 14/08/2009 16:57, Mariano Martinez Peck < marianopeck(a)gmail.com >
> escreveu:
>
>
>
>
> 2009/8/14 <csrabak(a)bol.com.br>
> Esteban,
>
> I'm comenting this on philosophical grounds.
>
> I understand the efforts to have SqueakDBX and other ORM in Pharo
> are motivated by Seaside and other "production" initiatives so,
> again, my food for thought is more an intellectual contribution
> which I see as useful for Pharo as project:
>
> I don't see Pharo any time soon® having all the toolset to be able
> to compete in the CRUD¹ realm with more streamlined tools and
> besides, not matter how much theoretical work has been done on ORM,
> the "impedance mismatch" is still there,
>
> Hi! I am agree with you about the "impedance mismatch". I think that
> if I am free to choose a persistence strategy I would use an OODB.
> However, if we are talking about real enterprise application (not a
> simple webpage) being able to choose the persistence strategy is
> practically impossible. We did a survey last year and the results
> were that most of the times you cannot choose. Of course, the client
> has a lot of reasons:
>
> - The client already has a RDBMS
> - They had paid for it and have the license (sometimes)
> - They want a company's support. The only company here is Gemstone.
> - RDBMS has history and it is an standard
> - They have knowledge about it
> - Interaction with other system (even legazy systems)
> - They are afraid of using another persistence strategy
> - They want to use SQL
> - They have DBAs
> - The persistence is difficult to negotiate
>
> So. In my opinion, if Pharo wants to be used really as a platform
> for enterprise applications (competing to java, .NET, etc), it must
> have a good relational solution. Of course, when you are able to
> choose, you can go for another approach like OODB.
>
> Best,
>
> Mariano
> a recent and practicall account of this (for Squeak) can be found in
>
> http://onsmalltalk.com/simple-image-based-persistence-in-squeak
>
> also, AIDA/Web has been able to run only storing thing in the image!
> See
>
> http://groups.google.com/group/comp.lang.smalltalk/browse_thread/thread/d3b…
>
> Since we'll increase the educational efforts to spread Pharo, I
> think that as technology we should to recover a bit of Smalltalk
> technology and be first more Object Oriented and then see if ORM
> still is so needed.
>
> my 0.0199999....
>
> --
>
> Cesar Rabak
>
> [1] http://en.wikipedia.org/wiki/Create,_read,_update_and_delete
> Em 14/08/2009 16:14, Esteban A. Maringolo < emaringolo(a)gmail.com >
> escreveu:
>
>
> My prototype is getting less proto, and I found out it doesn't have
> complex relations, and the system is going to perform faster if I have
> tables for most of it.
>
> What are the choices I have for doing ORM in Pharo?
>
> ¿Does GLORP work? ¿Any other options?
> I don't have a strong preference for the RDBMS engine, it can be
> anything (free), being it MySQL, PostgreSQL or Sql Server Express.
>
> Best regards,
>
> Esteban A. Maringolo
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project(a)lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project(a)lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project(a)lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project(a)lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Aug. 16, 2009
Re: [Pharo-project] Create a changeset for an entire package?
by Stéphane Ducasse
On Aug 15, 2009, at 7:54 PM, Javier Pimás wrote:
> Thanks for all the answers. I used Mariano's way, but I'd like to
> learn to do this monticello.
>
> Stephane, I didn't understand the method you proposed. Anyway, there
> are two problems that I need to solve:
>
> a) I don't wan't to include everything I changed from the package.
> There are some things that I changed for debugging. So, I can't
> fileout everything and I don't know if monticello will let me do
> what I want.
so far you cannot in MC
> b) Supose the change includes 3 separate packages, that should be
> seen as a one. Loading only one package only would break things, so
> I'd like the change to include all 3 in one operation.
as I said :)
you create an empty package called SLICEMyChanges you click on the
button add dirty packages as dependent
and you save the SliceMyChanges in the inbox.
This way I can load all the packages of your changes in one click and
without losing hours.
Check the how to submit changes on the wiki.
Stef
>
> Can this be done?
>
> On Fri, Aug 14, 2009 at 7:44 PM, Stéphane Ducasse <stephane.ducasse(a)inria.fr
> > wrote:
> save your package with monticello.
> Create a package empty call sliceXXX and add the dirty package as
> dependent (one click button)
> and publish it.
> MC has good supprt for merging.
>
>
> On Aug 14, 2009, at 4:08 PM, Javier Pimás wrote:
>
> > It seems fixing bugs is not the only hard part... I've a bunch of
> > fixes for GLCanvas, and a small proposed change for the class
> > browser but I can't find a way to export a diff of all the changed
> > packages, nor a diff of an entire package nor a diff of a class so
> > anybody can see the changes before commiting... Do I have to file
> > out every class I changed? there has to some easier way.
> >
> > Thanks,
> > Javier.
> >
> > --
> > Javier Pimás
> > Ciudad de Buenos Aires
> > _______________________________________________
> > Pharo-project mailing list
> > Pharo-project(a)lists.gforge.inria.fr
> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project(a)lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
>
> --
> Javier Pimás
> Ciudad de Buenos Aires
> _______________________________________________
> Pharo-project mailing list
> Pharo-project(a)lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Aug. 16, 2009
Re: [Pharo-project] Question about MD5
by Stéphane Ducasse
sure!
and you open a ticket flagged as 1.0
Stef
On Aug 15, 2009, at 9:01 PM, Mariano Martinez Peck wrote:
> Ok then...can I commit it in inbox?
>
> best,
>
> Mariano
>
> 2009/8/14 Henrik Johansen <henrik.s.johansen(a)veloxit.no>
> Strange, retested now.
>
> With .cs from 1065 also installed I got (first result with what I
> posted):
> Time millisecondsToRun: [500 timesRepeat: [largestByteArray hex]]
> 23267 32033
>
> and without it:
> Time millisecondsToRun: [500 timesRepeat: [largestByteArray hex]]
> 38877 50751
>
> Guess I tested the old version in an image without 1065 when I wrote
> the 2x :)
>
> Cheers,
> Henry
>
> On Aug 14, 2009, at 3:18 58PM, Mariano Martinez Peck wrote:
>
>>
>>
>> 2009/8/14 Henrik Johansen <henrik.s.johansen(a)veloxit.no>
>> I added a version to the issue which is almost 2x faster (for large
>> ByteArrays at least). I'm not sure if the needs of DBX are such
>> that the performance increase can justify the added uglyness (using
>> to:do: instead of do: ), but it'd be nice if you would have a look.
>>
>> Henry: Thanks for your feedback and work! I tried both solutions.
>> The one I posted, with your benchmark give me 34734. However, with
>> your version, I have 29675.
>>
>> best,
>>
>> Mariano
>>
>>
>> Cheers,
>> Henry
>>
>> On Aug 13, 2009, at 3:23 08PM, Mariano Martinez Peck wrote:
>>
>>> Ok. I opened the ticket: http://code.google.com/p/pharo/issues/detail?id=1067
>>>
>>> I replaced _ to := and take into considerations the henrik
>>> suggestions.
>>>
>>> Best,
>>>
>>> Mariano
>>>
>>> On Thu, Aug 13, 2009 at 9:47 AM, Henrik Johansen <henrik.s.johansen(a)veloxit.no
>>> > wrote:
>>> Please also use (String new: (self size * 2)) writeStream instead of
>>> '' writeStream.
>>> In this case it won't lead to any noticeable performance increases,
>>> but it's good practice anyways :)
>>>
>>> I'd also argue the expected returnvalue of "hex" might not be
>>> clear as
>>> something like "asHexString" when applied to a collection (hex
>>> previously only implemented on single values), but that's a minor
>>> issue.
>>>
>>> When looking around, I also noticed WriteStream nextPut: does an
>>> unnecessary check for ByteStrings which is pretty ugly (plus, it
>>> decreases nextPut: performance for all ByteString writeStreams),
>>> filed
>>> as Issue 1065.
>>>
>>> Cheers,
>>> Henry
>>>
>>>
>>> Issue 1065
>>> On Aug 13, 2009, at 10:32 19AM, Stéphane Ducasse wrote:
>>>
>>> > add a nice method comment and a couple of tests!
>>> >
>>> > Stef
>>> >
>>> > On Aug 13, 2009, at 1:26 AM, Mariano Martinez Peck wrote:
>>> >
>>> >> Hi folks: Me and the rest of the team is developing SqueakDBX
>>> which
>>> >> is a driver to talk with major databases. However, I think the
>>> most
>>> >> persistence alternatives pharo has, the best. There is no better
>>> >> solution for every escenario. So, I am also trying to get the
>>> >> PostgreSQL native driver to work in Pharo. This package depends
>>> on
>>> >> Cryptography because of MD5. I know that there were added to
>>> Pharo
>>> >> packages like System-Hashing-core, System-Hashing-SHA1 and
>>> System-
>>> >> Hashing-MD5. However, the driver doesn't work yet. But adding
>>> this
>>> >> single method:
>>> >>
>>> >> ByteArray>>hex
>>> >> | stream |
>>> >> stream _ '' writeStream.
>>> >> self do: [ :each |
>>> >> stream
>>> >> nextPut: ('0123456789ABCDEF' at: each // 16 + 1);
>>> >> nextPut: ('0123456789ABCDEF' at: each \\ 16 + 1)].
>>> >> ^ stream contents
>>> >>
>>> >> The driver works like a charm in Pharo without needing
>>> Cryptography
>>> >> package. As far as I remember there were no MIT problem with this
>>> >> package. Because of this those packages ( System-Hashing-core,
>>> >> System-Hashing-SHA1 and System-Hashing-MD5) were integrated in
>>> Pharo.
>>> >>
>>> >> So, can I add it?
>>> >>
>>> >> Thanks
>>> >>
>>> >> Mariano
>>> >> _______________________________________________
>>> >> Pharo-project mailing list
>>> >> Pharo-project(a)lists.gforge.inria.fr
>>> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>> >
>>> >
>>> > _______________________________________________
>>> > Pharo-project mailing list
>>> > Pharo-project(a)lists.gforge.inria.fr
>>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-
>>> project
>>> >
>>>
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> Pharo-project(a)lists.gforge.inria.fr
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> Pharo-project(a)lists.gforge.inria.fr
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> Pharo-project(a)lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>> _______________________________________________
>> Pharo-project mailing list
>> Pharo-project(a)lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project(a)lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project(a)lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Aug. 16, 2009
Re: [Pharo-project] OBDependencyWalker for Pharo
by Stéphane Ducasse
I imagine that david did that because he could not touch the code.
I hope that with the new OB release things will get clarified and
better.
Stef
On Aug 15, 2009, at 3:11 PM, Hernán Morales Durand wrote:
> Hi Cesar,
> Please update to the latest version of the DependencyBrowser. I was
> using a ClassSortFilter for filtering packages (which is wrong), and
> there are two different implementations of this message from David and
> Lukas:
>
> OBClassSortFilter>>nodesFrom:forNode:
>
> The one from David was preventing to send #theClass
>
> classNodes := nodes select: [ :ea | ea respondsTo: #theClass ].
>
> but I don't know which one is the right one, the implementation from
> Lukas is newer and usually his releases works pretty fine. Recently
> Colin posted another OB version, I hope the work done in OB gets a
> better coordination, it would be such a sad thing to have good
> incompatible versions of the framework.
> Cheers,
>
> Hernán
>
> 2009/8/14 <csrabak(a)bol.com.br>:
>> Hernán,
>>
>> I also don't have the expertise to debug it, but could you get more
>> info if
>> you put a #theClass method in OBClassSort with a sefl halt on it?
>>
>> It will avoid the sending of messages upstream in the "food chain"...
>>
>> Em 14/08/2009 09:05, Hernán Morales Durand <
>> hernan.morales(a)gmail.com >
>> escreveu:
>>
>> Ok, I found this could be related with an OB installation using this
>> script: http://code.google.com/p/pharo/wiki/ImageBuildScripts
>> I've loaded "AST", "Refactoring", "OmniBrowser" and "Tools". Then
>> loaded the DependencyBrowser, selected a package and gotcha, the
>> #theClass MNU was raised.
>> However I wasn't able to debug it (please see the attachement), the
>> stack isn't displayed in the debugger and some operations (Out, Over,
>> etc) hang the image and I have interrupt with Alt+.
>> Cheers
>>
>> Hernán
>>
>> 2009/8/14 Stéphane Ducasse :
>>> apparently there was a change in OB and it would be good to
>>> understand
>>> because
>>> we have some open issues that are related to that.
>>>
>>> Stef
>>>
>>>
>>>> Oh, that page was obsolete sorry about that, working with PHP
>>>> pages is
>>> &g t; so... fuckin horrible!
>>>> However that's not the issue here. I need to do a little research
>>>> to
>>>> see why the Dependency Browser breaks with mysterious OB stuff? I
>>>> will
>>>> update the repository as soon as I find the cause.
>>>> Thanks for reporting
>>>>
>>>> Hernán
>>>>
>>>> 2009/8/13 :
>>>>> Em 13/08/2009 21:34, Hernán Morales Durand
>>>>> escreveu:
>>>>>
>>>>>> Hi csrabak,
>>>>>> Thanks for the feedback. I wonder how you've installed the DW?
>>>>>
>>>>> I followed
>>>>> http://cs.hernanmorales.com.ar/projects/dependencyBrowser/DBrowser-fr.php
>>>>> (Overture Pharo) tab (but I bet you _knew_ that ;-)!
>>>>>
>>>>> Notice I installed on Pharo1.0beta image. . . and use only
>>>>> "default" settings. . .
>>>>>
>>>>>> Anyone else experi mented this trouble?
>>>>>
>>>>> This is something I cannot answer :-(
>>>>>
>>>>>> That MNU is fine, the problem is that message should never be
>>>>>> sent
>>>>>> to
>>>>>> an OBInheritanceDependencyNode. Please note the two leftmost
>>>>>> panes
>>>>>> (columns) in the DependencyBrowser contains system categories or
>>>>>> "packages", not classes.
>>>>>> So I've tried to reproduce your problem with the three OB
>>>>>> installations from Pharo:
>>>>>>
>>>>>> ScriptLoader loadOB.
>>>>>> ScriptLoader loadSuperOB.
>>>>>> ScriptLoader loadOBAlpha.
>>>>>>
>>>>>> selected every system category, gathering all dependencies in
>>>>>> your
>>>>>> Pharo version, and still cannot find that MNU. Can you provide me
>>>>>> further details about it?
>>>>>>
>>>>>> Are you using latest OmniBrowser?
>>>>>
>>>>> I do supose so as at the time I wrote the e-mail I had the image
>>>>> uptodate (#10413).
>>>>>
>>>>>> Have you installed the DependencyBrowser with the script of my
>>>>>> previous e-mail?
>>>>>
>>>>> I ran the script of your page.
>>>>>
>>>>>> This is happening when you select a particular package?
>>>>>
>>>>> Any package will do, but to stick to a simple one I click in
>>>>> "OmniBrowser" and kaboom!
>>>>>
>>>>>> Have you installed additional OB packages?
>>>>>
>>>>> I lost the control of what is considered "aditional" wrt to OB. So
>>>>> I attach the browser of the image I'm testing it:
>>>>>
>>>>> HTH
>>>>>
>>>>> --
>>>>> Cesar Rabak
>>>>>
>>>>> _______________________________________________
>>>>> Pharo-project mailing list
>>>>> Pharo-project(a)lists.gforge.inria.fr
>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-
>>>>> project
>>>>>
>>>>
>>>> _______________________________________________
>>>> Pharo-project mailing list
>>>> Pharo-project(a)lists.gforge.inria.fr
>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> Pharo-project(a)lists.gforge.inria.fr
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>
>> ________________________________
>>
>> _______________________________________________
>> Pharo-project mailing list
>> Pharo-project(a)lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project(a)lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Aug. 16, 2009