David,
I concur that while progress has been made my meta-issues have not been
addressed. I think that effectively addressing using the current model and
retaining something resembling API compatibility would be a huge task, and
probably would have meant that very little newness from a
feature-f
...or carrier pigeon...
http://www.neatorama.com/2009/09/10/httpwww-reuters-comarticleoddlyenoughnewsidustre5885pm20090909/
On Mon, Sep 21, 2009 at 7:14 PM, Meredith Gregory
wrote:
> Dear Chas,
>
> Didn't you know... more than half the data in world is still flying over
> sneakernet. ;-)
>
> Bes
Yes, particularly maxPoolSize.
On Wed, Sep 16, 2009 at 10:25 AM, Atsuhiko Yamanaka <
atsuhiko.yaman...@gmail.com> wrote:
>
> Hi,
>
> On Wed, Sep 16, 2009 at 10:33 PM, Erik Engbrecht
> wrote:
> > The large number of VolatileTaskRefs is a consequence of your thread po
The large number of VolatileTaskRefs is a consequence of your thread pool
growth. Each worker thread maintains an array of VolatileTaskRef objects.
The VolatileTaskRef objects are reused rather than allocated for each task,
so they will not be GC'd as long as the worker thread is alive. You can
t
It's responding for me. If you use a browser, can you get to
http://scala-tools.org ?
On Wed, Jul 15, 2009 at 12:03 PM, Dano wrote:
>
> Trying to build my scala/lift app and my maven is hung up on scala-
> tools.org. The machine tied to the domain is pingable but does not
> service otherwise.
For the record, no one from the EPFL or otherwise affiliated with it has
responded to issue #2009.
On Sun, May 24, 2009 at 1:56 PM, David Pollak wrote:
>
>
> On Sun, May 24, 2009 at 1:46 AM, marius d. wrote:
>
>>
>> I'm wondering maybe it would be good to abstract the actors in Lift
>> such that
Greg, It's not exactly deadlock, but you may find this interesting:
https://lampsvn.epfl.ch/trac/scala/ticket/1999
-Erik
On Tue, May 19, 2009 at 5:34 PM, Meredith Gregory
wrote:
> David,
>
> Bravo! That sounds to be some gnarly sleuthing-n-hacking. BTW, have you run
> into any deadlock issues
Glenn,
Just out of curiosity, what's your frame of reference, e.g. the
technologies that you are accustomed to that are so much more
"interoperable"? Based on some recent experience teaching Django to
ASP.NETdevelopers, it seems to me your experience may be leading you
to look for
things that ju
Actors can be, and often are, dependent on messages from other actors to do
their thing. So if you're not careful you can end up with them waiting on
each other indefinitely.
On Mon, Jan 19, 2009 at 2:18 PM, tim wee wrote:
> Hi Jorge,
> Thanks for the thoughtful reply.
>
> For the deadlock/live
My standard procedure is to go into .netbeans and rename the directory for
my current version (I've been using the dev build, so it is called dev) so
that I have a backup and can revert.
I have found always starting with a clean directory is .netbeans is key.
On Mon, Dec 1, 2008 at 8:09 PM, David
I think you need to be able to quantify the risk versus reward for your
clients. You should also be able to tell them how you mitigate some of that
risk. For example, a lot of custom software is delivered in a half-baked
state. If you deliver a half-baked product, and then move on to the next
pr
I haven't tried this, but if possible I'd suggest moving them into a
separate libary and only letting NetBeans see the compiled jar.
As a side note, I bet the Eclipse plugin has the same problem. They are
both use pieces of Scala compiler, and anything that makes the compiler work
hard makes the
Are the presentations going to be made available to the non-conference
attending public?
This is huge. I wish I had been paying more attention to the Lift list.
On Fri, Aug 29, 2008 at 11:32 AM, David Pollak <[EMAIL PROTECTED]> wrote:
>
>
> Tim Perrett wrote:
>
> I'm on the fence about this bei
13 matches
Mail list logo
