> Not exactly. For example, I see this under alib:
> Instead of just:
> I didn't even realize that GForge allowed identical release
> the same package. Maybe this has nothing to do with the problem,
> however. I'm just guessing.
ah. didn't know you could do that! in any case i've been
doing for a looong time so i'm sure it's not the problem in
this case... i'll look into it for my rubyforge script.
Yes, when you put out a release (using the web form) you'll see an
option to "Add file to this release". That's what I use. I prefer my
approach because it's a little less confusing (to me), and saves screen
real estate. I have a feeling it's also easier to manage in terms of
show/edit in the Admin section.
For example, if you wanted to hide the 0.3.1 release for alib, wouldn't
you have to perform two edits? One for the gem and one for the .tgz
But, hey, far be it from me to tell you how to organize your project.
> It would require C I'm afraid. The win32-open3 package is one of
> those that can't properly be converted to pure Ruby.
Perhaps a simple
> facade is in order.
that's ok. a facade would be fine.
>> next i'll have you help me make posixlock cross-platform
> I haven't looked at the source yet, but I suppose I would start with
> Lock() and LockEx():
right. i'd like both those and fctnl (posix) based locking
wrapped into a single
interface that mimics File#flock
if you have a minute check out posixlock - it's really short.
which win32 lib
might already have locking builtin?
The wrappers for the raw C functions would be in windows-pr
(windows/file). However, I just realized I haven't included the
appropriate constants for those functions (dangit). I'll do that this
I'll take a look at posixlock and see what I can come up with.
This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly
prohibited and may be unlawful. If you have received this communication
in error, please immediately notify the sender by reply e-mail and destroy
all copies of the communication and any attachments.
On Fri, 1 Sep 2006, Berger, Daniel wrote: