Stef,
It would be nice to tackle 2476 (ConnectionQueue) and 1057 (named serial
ports). I have what might be better called improvements than fixes. For 1057,
the comments suggest that I might be fairly far off, having dealt only with
getting the code to work. The way the vm (Linux at least) i
Right or wrong (not sure which), I have always thought of meta classes as
breaking a recursion that arises when classes aspire to be objects that have
all have a class. Is there such a thing as private instance variables? Could
that mean the header, special behavior masks (a Dolphinism), etc.?
This would be most welcome. But it should be useful for more than just morphs.
In particular, I am thinking of printing where one has to paginate and
sometimes represent things differently than would be done on screen. A post
script canvas or similar entry points should do it.
-Orig
t be drawn,
do you halt the system? Right now it is not the case, a rectangle with a cross
is drawn.
In any case, I am open to suggestions for improvement!
On 23 Oct 2010, at 18:46, Schwab,Wilhelm K wrote:
> I don't like the idea of instantiating red if the name is not recognized.
Stasenko
[siguc...@gmail.com]
Sent: Saturday, October 23, 2010 10:47 PM
To: Pharo-project@lists.gforge.inria.fr
Subject: Re: [Pharo-project] some patterns I would like to **kill**
On 23 October 2010 21:47, Schwab,Wilhelm K wrote:
> Hey, I want some credit here - for coming to Squeak's possible
I don't like the idea of instantiating red if the name is not recognized.
Since you don't have selectors (900+ might be a bit much), the compiler/Shout
won't catch mistakes, and it will be an ongoing source of silent failures.
From: pharo-project-boun
SmartReferenceStream is indeed complicated, but it is also poorly designed.
Dolphin's binary filer intuitively places versioning (of the serialized data
streams) on the class side of each serialzed class or a proxy for same. The
result is that the filer itself does not change as the classes it
-boun...@lists.gforge.inria.fr] On Behalf Of Igor Stasenko
[siguc...@gmail.com]
Sent: Saturday, October 23, 2010 11:00 AM
To: Pharo-project@lists.gforge.inria.fr
Subject: Re: [Pharo-project] some patterns I would like to **kill**
On 23 October 2010 17:13, Schwab,Wilhelm K wrote:
> Stef,
>
> Of course.
: [Pharo-project] some patterns I would like to **kill**
I think that if you have a container that contains morphs probably findA and
other queries are useful.
Now for a button that is also at the same place a field is the best.
Stef
On Oct 22, 2010, at 11:14 PM, Schwab,Wilhelm K wrote:
> S
Stef,
#respondsTo: - no argument. More defensive programming (aka masked bugs).
Tests like this have their place, but are over-used in Squeak.
Using #submorphs *might* be easier to defend. Morphs were designed to be
usable in large numbers, and one might argue (playing Devil's Advocate here)
I haven't had much trouble with it. You can look in the inbox for Migrate (for
how I load it) and the DolphinCompatibility package for things that I have
added to the ODBC support.
From: pharo-project-boun...@lists.gforge.inria.fr
[pharo-project-boun.
Paolo,
Thanks for the reference. I will give it a good look.
Bill
From: Paolo Bonzini [paolo.bonz...@gmail.com] On Behalf Of Paolo Bonzini
[bonz...@gnu.org]
Sent: Wednesday, October 20, 2010 2:13 PM
To: Schwab,Wilhelm K
Subject: Fwd: Re: Plug-in
Göran,
I found your Syslog package, and was quick to lean toward the FFI form largely
because when combined with Gnome's log file viewer and a filter, it will
hopefully be similar to OutputDebugString + DebugView on Windows. I had to
change the call to
syslog: severity message: aString
Behalf Of Mariano Martinez
Peck [marianop...@gmail.com]
Sent: Monday, October 18, 2010 3:30 PM
To: Pharo-project@lists.gforge.inria.fr
Subject: Re: [Pharo-project] Some questions about pharo
On Mon, Oct 18, 2010 at 9:05 PM, Schwab,Wilhelm K
mailto:bsch...@anest.ufl.edu>> wrote:
The Windo
The Windows vm displays a system tray icon that allows the image to leave the
headless state. It has been quite useful, but there should be (hopefully is) a
way to prevent that.
From: pharo-project-boun...@lists.gforge.inria.fr
[pharo-project-boun.
I don't know if it's better (or even as good), but when the dust settles, it
would be nice to have something _called_ SharedQueue that does what's expected
of it and delegates to the improved classes. Another option would be to go
through a deprecation period with SharedQueue.
___
need to load this
once. (including seaside and other 3rd party tools)
Regards,
Bart
2010/10/18 Schwab,Wilhelm K :
> I am not clear on upgrades, but I strongly urge establishing a process for
> saving and loading packages and data, otherwise you can end up trapped in a
> very old im
I am not clear on upgrades, but I strongly urge establishing a process for
saving and loading packages and data, otherwise you can end up trapped in a
very old image. SIXX has done well for me so far with data. What don't you
understand about loading?
For saving and loading packages, I use a
I don't know why the Windows VM does not signal the semaphore. There are, of
course, good and bad possible reasons why that might be.
The up side includes possible motives of compensating for weirdness in the
Windows event queue over the many versions. Dolphin tries to be correct about
it,
Are you sure? I see an OK button at the bottom right of About in an image that
identifies itself the same way.
From: pharo-project-boun...@lists.gforge.inria.fr
[pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Bernhard Pieber
[bernh...@piebe
Are those negative numbers in the Squeak stats?
From: pharo-project-boun...@lists.gforge.inria.fr
[pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Nicolas Cellier
[nicolas.cellier.aka.n...@gmail.com]
Sent: Saturday, October 16, 2010 9:37 AM
To
Bart,
My image is 40 MB right now. That means you have about 100 MB of data? How do
you store it? How many objects are there? Are they of fixed size? If so, you
might try a quick experiment using a String or ByteArray wrapped with something
that knows how to find a given code. You might b
va. However, I found that making least-square fits
within the time required to refresh a screen perfecttly acceptable
compared to the unstability of cross language communication.
Cheers,
Didier
On 14/10/2010 22:36, Schwab,Wilhelm K wrote:
> That is wonderful news!
>
> Didier, There
Why should it be free? It might be nice to have an electronic copy, or just
permission to scan and release, in escrow. That could be done quietly between
Didier and ESUG, and triggered if the book is no longer in print. If it is in
print and the code is worth having we should be buying copies
That is wonderful news!
Didier, There is a natural question that arises: what are the performance
implications of Smalltalk or Java? Why not C with a Smalltalk wrapper? I have
not tried number crunching with Cog or NativeBoost doing some of the expensive
lifting, but absent those advantages,
FWIW, Dolphin has (or at least had in earlier versions - I can check later if
it matters) an analog to #valueUnpreemptively. Something like that is likely
to be more portable than new syntax or a new bytecode. Any VW experts care to
comment on what might be available there?
Bill
__
, 2010 10:30 AM
To: Pharo Development
Subject: [Pharo-project] Fwd: License question
Begin forwarded message:
> From: Paolo Bonzini
> Date: October 13, 2010 3:38:49 PM GMT+02:00
> To: "Schwab,Wilhelm K"
> Cc: "Fitzell, Julian" , "stephane.duca...@inria.fr&
+1
From: pharo-project-boun...@lists.gforge.inria.fr
[pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Alexander Lazarević
[l...@blobworks.com]
Sent: Wednesday, October 13, 2010 9:03 AM
To: Pharo-project@lists.gforge.inria.fr
Subject: Re: [Pharo
tification
do: [:ex | ].
Any idea how I can make the popup not open?
Cheers,
Alexandre
On 12 Oct 2010, at 17:42, Schwab,Wilhelm K wrote:
> First, did you open the window (as in it's the point of the test), or did
> Pharo open it in contradiction to your better judgment? If the latter
The tests I am finding in my Dolphin image create/show a presenter, do some
things to it, and then use #ensure: to evaluate
aPresenter topShell presenter exit.
after which it forces a check of the finalization queue and a GC; I probably
did that out of an abundance of caution.
Bill
__
First, did you open the window (as in it's the point of the test), or did Pharo
open it in contradiction to your better judgment? If the latter, what is
happening?
Assuming that you have opened a modal window in a test, there are a couple of
ways that I have handled such things in Dolphin. Fi
I've played similar games for a long time. Originally, I had to run on a
Novell network, and it was a BSOD waiting to happen. So, I added a machine
with the Novell client that did nothing but use a mapped drive to read from a
source and push data over TCP/IP to my server, which happily no long
tasenko
[siguc...@gmail.com]
Sent: Monday, October 11, 2010 6:35 PM
To: Pharo-project@lists.gforge.inria.fr
Subject: Re: [Pharo-project] Another finalization concern: error handling
On 12 October 2010 00:32, Schwab,Wilhelm K wrote:
> Sig,
>
> How hard it is or isn't is not nearly as impo
er finalization concern: error handling
On 11 October 2010 22:49, Schwab,Wilhelm K wrote:
> Sig,
>
> The most important words in there are "critical section." Carry on :)
>
Oh, please. This is not too hard to code.
My mind rolling around following choice(s) (there may be
October 11, 2010 2:36 PM
To: Pharo-project@lists.gforge.inria.fr
Subject: Re: [Pharo-project] Another finalization concern: error handling
On 11 October 2010 21:07, Schwab,Wilhelm K wrote:
> Sig,
>
> As a friend here: when did I say I'd remove all? Remove and process one at a
> ti
ubject: Re: [Pharo-project] Another finalization concern: error handling
On 11 October 2010 20:04, Schwab,Wilhelm K wrote:
> Sig,
>
> Understood, but are they all that different? The ones that were served ahead
> of the error should stay that way (proper recording of same is what ne
Stef,
Let's go forward in time. NativeBoost, Alien or FFI provide callbacks, I do
some adaptation on my end, and out comes a pretty capable wrapper for the GNU
Scientific Library. That sentence trivializes a LOT of work :( Details
aside, is the wrapper code itself affected by GPL, or is it
oject] Another finalization concern: error handling
On 11 October 2010 19:28, Schwab,Wilhelm K wrote:
> Sig,
>
> The Dolphin approach is to restart any of the finalizer, main, timer, idler
> threads (I *think* there is one more in a baseline image) any time they quit;
> an #ensur
oject@lists.gforge.inria.fr
Subject: Re: [Pharo-project] Another finalization concern: error handling
On Mon, 11 Oct 2010, Schwab,Wilhelm K wrote:
> Henry,
>
> Ok, what valid use of multiple executors have I missed?
I described it earlier how the AXAnnouncements project uses this feature.
Lev
Sig,
The Dolphin approach is to restart any of the finalizer, main, timer, idler
threads (I *think* there is one more in a baseline image) any time they quit;
an #ensure: block forks a new thread of the type that terminated. That way,
whether they are taken down by an error doing what they are
Nick,
I'm certainly no expert on DST, but I will gladly help where I can. You're
starting a PhD program? Is Stef your advisor? That would put you in good
hands.
Bill
From: pharo-project-boun...@lists.gforge.inria.fr
[pharo-project-boun...@lists.gfo
, 2010 11:23 AM
To: Pharo-project@lists.gforge.inria.fr
Subject: Re: [Pharo-project] Another finalization concern: error handling
On Oct 11, 2010, at 4:10 13PM, Schwab,Wilhelm K wrote:
>
> I am far more worried about having multiple executors per object (when did
> p=malloc();free(p);free(
[pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi
[le...@elte.hu]
Sent: Monday, October 11, 2010 10:59 AM
To: Pharo-project@lists.gforge.inria.fr
Subject: Re: [Pharo-project] Another finalization concern: error handling
On Mon, 11 Oct 2010, Schwab,Wilhelm K wrote
ect: Re: [Pharo-project] Another finalization concern: error handling
On 11 October 2010 17:24, Levente Uzonyi wrote:
> On Mon, 11 Oct 2010, Schwab,Wilhelm K wrote:
>
>> Levente,
>>
>> A similar discussion arose around Dolphin's event (#trigger*) mechanism.
>>
a
setter to be able to migrate a whole hierarchy of classes elsewhere ?
Ok.. hope next time I will posting code instead of questions.
Thank you very much,
Nick
On Mon, Oct 11, 2010 at 3:59 PM, Schwab,Wilhelm K
mailto:bsch...@anest.ufl.edu>> wrote:
I'm glad to see that it works like
Dolphin has all of its required processes rigged to restart themselves if
terminated; we must follow that lead. As far as getting error information from
one thread to another, in one case I grab a callstack (just the This>>that,
That>>this text with line feeds) and capture it to be included as
ia.fr
[pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi
[le...@elte.hu]
Sent: Monday, October 11, 2010 10:24 AM
To: Pharo-project@lists.gforge.inria.fr
Subject: Re: [Pharo-project] Another finalization concern: error handling
On Mon, 11 Oct 2010, Schwab,Wilhelm K wrote:
>
.. namespaces in the system level
?
On 11 October 2010 16:59, Schwab,Wilhelm K wrote:
> I'm glad to see that it works like class names (at least effectively) as
> messages to environments than a clone of Java syntax that I saw elsewhere.
> On the completely pragmatic level, it
Levente,
A similar discussion arose around Dolphin's event (#trigger*) mechanism. My
recollection is that it was not fully addressed due to performance concerns.
Forking and error handlers both have their costs. I'm not saying we should
necessarily follow (we probably should not), though wit
I'm glad to see that it works like class names (at least effectively) as
messages to environments than a clone of Java syntax that I saw elsewhere. On
the completely pragmatic level, it will make more obvious the fact that our
browser selection panes are not individually sizable. I find them
Behalf Of David T. Lewis
[le...@mail.msen.com]
Sent: Sunday, October 10, 2010 9:54 PM
To: Pharo-project@lists.gforge.inria.fr
Subject: Re: [Pharo-project] [squeak-dev] Re: WeakRegistry>>remove: - when
you'll be in trouble
On Sun, Oct 10, 2010 at 08:16:57PM -0400, Schwab,Wilhelm K wrote
Sig,
Dumb question: how much does an executor need to know about this? It can't
strongly bind the outgoing object or weaklings won't let go and finalization
will never happen. Whether the guidance to it is in the form of "clean up" or
"skip it," it needs to come from the weak registry, finali
Squeak]
Thanks Bill,
some of the link on this page seem dead though...
Nicolas
2010/10/10 Schwab,Wilhelm K :
> FWIW, SIF might help you:
>
> http://www.pocketsmalltalk.com/sif/
>
> I have put a lot of code through it in the past couple of years.
>
>
> ___
reams : first embryonary port on Squeak ]
Hi Bill,
I see, you're helping me to help myself :)
What I was looking at was more like a free lunch ;)
Nicolas
2010/10/10 Schwab,Wilhelm K :
> Nicolas,
>
> #fork in a test? Do you mean like the code below? The thread running the
> t
Just learned about this one:
http://mariadb.org/index.html
It sounds like the old guard of MySQL is coalescing around it. It's up to you
to decide whether that is true, and if so, whether it is a good thing.
___
Pharo-project mailing list
Pharo-p
It sounds like a double dispatch that, as that enables, gives the behavior one
would want in either case: evaluate the block and return its value, just give
the value of a magnitude (evaluating same is trivial), etc. The ambiguity
argument got me, but with a dispatch along the way, I think tha
An excellent point about ambiguity. The two examples
process ifNotNil:#terminate
and
something ifTrue:1 ifFlalse:0
appear to ask for perform and assign, respectively. Writing the brackets for
the latter is not a big chore, and the first example is solved with a new
message (#terminateM
Nicolas, Sig,
The problem is compiler inlining? That happens at compile time, right? :)
Unless I am missing something, I see no reason to get upset about what you
propose. The runtime cost from the added messages is decided when the code is
compiled, and things that are currently inlined wo
Nicolas,
Have you thought about using another message, something like
#terminateIfRunning that you put in both Process and UndefinedObject? Then you
can just send it w/o the test and w/o a compiler change.
Bill
From: pharo-project-boun...@lists.gfor
Sig,
Have you thought about using a Mutex? Maybe I'm missing something in life, but
long ago I decided the #forMutualExclusion is *beyond* private. Semaphores are
wonderful for #wait/#signal. But for #critical:, I use Mutex which won't
deadlock a thread with itself.
Bill
_
Nicolas,
#fork in a test? Do you mean like the code below? The thread running the test
waits on something signaled toward the end of the forked thread.
If you want a watchdog timer, you could fork another thread that waits on a
delay, sets an error flag (best to use a shared queue or a mute
FWIW, SIF might help you:
http://www.pocketsmalltalk.com/sif/
I have put a lot of code through it in the past couple of years.
From: pharo-project-boun...@lists.gforge.inria.fr
[pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Nicolas Cellie
oject@lists.gforge.inria.fr
Subject: Re: [Pharo-project] 12186 image quit problem
On Sat, Oct 9, 2010 at 2:05 PM, Schwab,Wilhelm K
mailto:bsch...@anest.ufl.edu>> wrote:
Sig,
Ignore this if you see fit; it might not apply, but don't dismiss it too
quickly - it will apply somewhere, somehow. First,
Max,
You are probably way ahead of this (and keep pushing the envelope), but you
do know about #release, right? A couple of weeks ago I ran some fairly intense
calculations that resulted in low space conditions. Sending #release to the
participants (and implementing it correctly) fixed it.
O
Sig,
Ignore this if you see fit; it might not apply, but don't dismiss it too
quickly - it will apply somewhere, somehow. First, are these things happening
on shutdown, or on image save? I ask because while they seem to be getting
straightened out over time, those concepts have long been inte
I thought your name was familiar. Hello!
One caution/suggestion about your idea: a piece of code could be left unchanged
because it is unused or poorly maintained. There are parts of the network,
streams, file system, etc. that *should* have changed long ago. Core concept
or complacency? Bu
Stef,
FWIW, the biggest problem I see with this is returning nil rather than raising
an exception. With that omission corrected, there are various ways I could
envision it working, probably centered on failing to open a writable stream,
but if one asks for a read-only stream, there would be no
Not sure I follow. Is this saying that one chooses between the default console
output and printAllStacks(), or is it making printAllStacks() happen in
response to the signal and leaving the usual output in place too? I guess
another option might be that all stacks get printed instead of just t
s.gforge.inria.fr] On Behalf Of Adrian Lienhard
> [...@netstyle.ch]
> Sent: Friday, October 08, 2010 8:21 AM
> To: Pharo-project@lists.gforge.inria.fr
> Subject: Re: [Pharo-project] 12186 image quit problem
>
> You can attach gdb to the VM and then call printAllStacks().
>
>
Thanks!
From: pharo-project-boun...@lists.gforge.inria.fr
[pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Torsten Bergmann
[asta...@gmx.de]
Sent: Friday, October 08, 2010 9:47 AM
To: pharo-project@lists.gforge.inria.fr
Subject: [Pharo-project]
You can attach gdb to the VM and then call printAllStacks().
HTH,
Adrian
On Oct 8, 2010, at 14:07 , Schwab,Wilhelm K wrote:
> Do you have access to anything that will dump the callstacks for "all"
> processes? One of my first encounters with the Squeak update streams was
>
Pavel,
You say it "hangs without error." Squeak fails silently in many situations in
the vms and the image, so a failure to provide diagnostic info is not a new
thought, but this sounds like a deadlock between finalization and something
else important - at least that is what I *think* I am rea
Torsten,
What do you do to test your newly converted Seaside apps? Have you automated
it, or is just a matter of trying everything yourself?
Bill
From: pharo-project-boun...@lists.gforge.inria.fr
[pharo-project-boun...@lists.gforge.inria.fr] On Behal
Do you have access to anything that will dump the callstacks for "all"
processes? One of my first encounters with the Squeak update streams was
trying to provide patches to the dump code... Similar features appeared years
later, I suspect unrelated to my efforts. What I did was hack the VM su
Stef,
Do you have any interest in my alternate protocol idea? In short, #next is
misleading even on VW. When I learned that, I pretty much gave up on a robust
implementation and did the logical thing: made the alternate selectors and
started writing all of my new code in terms of them. It is
l.com]
Sent: Thursday, October 07, 2010 7:58 AM
To: Pharo-project@lists.gforge.inria.fr
Subject: Re: [Pharo-project] Pointer types
On 7 October 2010 14:24, Igor Stasenko wrote:
> On 7 October 2010 14:09, Schwab,Wilhelm K wrote:
>> Sig,
>>
>> I have to start watching the clock
[siguc...@gmail.com]
Sent: Thursday, October 07, 2010 6:49 AM
To: Pharo-project@lists.gforge.inria.fr
Subject: Re: [Pharo-project] Pointer types
On 7 October 2010 13:35, Schwab,Wilhelm K wrote:
> Sig,
>
> Ultimately, I will have to simply try this, but it reminds me of something
&g
Do you see yourself acting as scientist or student? Good scientists *are*
students (learning never stops), but the distinction I am making is more about
what you plan to get from this. If you see this as a scientific exercise, you
will want to collect or map the changes to some type of reporta
-boun...@lists.gforge.inria.fr
[pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Igor Stasenko
[siguc...@gmail.com]
Sent: Thursday, October 07, 2010 12:41 AM
To: Pharo-project@lists.gforge.inria.fr
Subject: Re: [Pharo-project] Pointer types
On 7 October 2010 01:27, Schwab,Wilhelm K wrote:
> Sig,
>
>
Nicolas,
Did I not get any help? Sadly, there was so much bickering that it was hard to
tell. I think yours was the reply that I had in mind to revisit. What I will
do now, absent unforeseen time pressure, is put the offending calls on hold
until 1.2 and then add them to the package. Anothe
casse
[stephane.duca...@inria.fr]
Sent: Wednesday, October 06, 2010 6:02 PM
To: Pharo-project@lists.gforge.inria.fr
Subject: Re: [Pharo-project] Tests broken with Citezen
have a look at the configuration you can pick noWeb.
Stef
On Oct 6, 2010, at 7:17 PM, Schwab,Wilhelm K wrote:
> Damien,
>
&g
Stef,
Good enough, but it sounded like a higher level of cleaning was on the way??
Some of the code that I have using "Smalltalk at:" originally expected a
SystemDictionary. I have no problem with implementation changes, and I like
the #environment idea.
Bill
__
I'm not sure I follow your concern. The Win32 examples will certainly fail on
other than Win32. I am not even certain if they are currently expected to work
on Windows (not simply a dig at its flakiness - it might have changed enough to
break something). It looks like one is expected to click
From: pharo-project-boun...@lists.gforge.inria.fr
[pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Igor Stasenko
[siguc...@gmail.com]
Sent: Monday, October 04, 2010 7:36 AM
To: Pharo-project@lists.gforge.inria.fr
Subject: Re: [Pharo-project] Pointer types
On 4
arguments
El mié, 06-10-2010 a las 16:08 -0400, Schwab,Wilhelm K escribió:
> It might still work at first try, though your initial presentation of it left
> me expecting something else. Don't give up as quickly as you seem to think I
> do. I will admit that the legend support in PLp
half Of Nicolas Cellier
[nicolas.cellier.aka.n...@gmail.com]
Sent: Wednesday, October 06, 2010 3:30 PM
To: Pharo-project@lists.gforge.inria.fr
Subject: Re: [Pharo-project] FFI number of arguments
2010/10/6 Schwab,Wilhelm K :
> Nicolas,
>
> The "not trivial" did indeed reduce my int
ists.gforge.inria.fr
[pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Eliot Miranda
[eliot.mira...@gmail.com]
Sent: Wednesday, October 06, 2010 2:38 PM
To: Pharo-project@lists.gforge.inria.fr
Subject: Re: [Pharo-project] FFI number of arguments
Bill,
On Wed, Oct 6, 2010 at 10:24
ry for the rant, but please, help us to help you.
Back to the technical problem, did the updated version at
http://www.squeaksource.com/Smallapack/Compiler-nice.150.mcz help, or
did my words "not trivial" stopped you?
Nicolas
2010/10/6 Schwab,Wilhelm K :
> Miguel,
>
> I do not &q
PM
To: Pharo-project@lists.gforge.inria.fr
Subject: Re: [Pharo-project] FFI number of arguments
El mié, 06-10-2010 a las 12:33 -0400, Schwab,Wilhelm K escribió:
> Miguel,
>
> I see it very differently: I do extensive searches and summarize the results,
> dropping keywords along the way that I wish had b
Damien,
FWIW, I use Citezen but not Pier etc. I need a good BibTeX parser (which you
provide) to parse incoming entries (typically originating from Google Scholar).
I then add fields for my own comments (which get edited as I work) and a URL
to full text and save the result to intermediate st
Stef,
You raise a good point about helping to improve code, and I would MUCH rather
see us try "aClass environment" for a while before introducing name spaces.
Dolphin started leaning toward environments a long time ago, and suddenly
"class names" were messages to the environment, and I was co
_
From: pharo-project-boun...@lists.gforge.inria.fr
[pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Miguel Cobá
[miguel.c...@gmail.com]
Sent: Wednesday, October 06, 2010 12:13 PM
To: Pharo-project@lists.gforge.inria.fr
Subject: Re: [Pharo-project] FFI number of arguments
El m
Stefan,
I don't fully understand what you have in mind, but the thought that packaging
is weak in Pharo is not a new one. In the early days of Dolphin's packaging
system, it was not terribly good about loading prerequisites (that improved
greatly over time), so I built a tool called Migrate th
-boun...@lists.gforge.inria.fr
[pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi
[le...@elte.hu]
Sent: Tuesday, October 05, 2010 11:09 PM
To: Pharo-project@lists.gforge.inria.fr
Subject: Re: [Pharo-project] FFI number of arguments
On Tue, 5 Oct 2010, Schwab,Wilhelm K wrote
Does the crash happen if the plugin is built on a machine without the library,
or if it is run on a machine without it?
From: pharo-project-boun...@lists.gforge.inria.fr
[pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi
[le...@e
[le...@elte.hu]
Sent: Tuesday, October 05, 2010 10:26 PM
To: Pharo-project@lists.gforge.inria.fr
Subject: Re: [Pharo-project] FFI number of arguments
On Tue, 5 Oct 2010, Schwab,Wilhelm K wrote:
> Hello all,
>
> I have been bumping into some functions with large numbers of argumen
Stef,
No problem. When I saw the subject line, I thought it was a party for Pharo,
but you're worthy of a little celebration too :)
Bill
From: pharo-project-boun...@lists.gforge.inria.fr
[pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Stép
Hello all,
I have been bumping into some functions with large numbers of arguments. One
in particular would be best handled in the image if at all possible. The
following might be the answer:
http://thread.gmane.org/gmane.comp.lang.smalltalk.squeak.general/98538/focus=98543
Have any of y
Hello all,
For 1.1.1, it works - thanks!! Another nice thing is that gedit is willing to
open the debug log from 1.1.1 (an encoding fix??).
Bill
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi
Well, I *thought* I could, until I noted where it sits in the list of packages
in the image I just built - after Magritte. That had me wondering whether it
came in with Seaside (not impossible), but it is also just in front of SIXX:
ftp://swikis.ddo.jp/SIXX/squeak/SIXX20091115.sar
which can
701 - 800 of 2086 matches
Mail list logo
