[Ready for test/1.5.0] tiff

[Charles Wilson]

tiff-3.6.0-3
libtiff4-3.6.0-3
libtiff-devel-3.6.0-3
This is NOT to be confused with today's non-test release of 
tiff-3.6.0-2, libtiff3-3.6.0-2, and libtiff-devel-3.6.0-2.  The new, 
curr: release has 'cygtiff3.dll' while the new test: release
has cygtiff4.dll.

BTW, maintainers: note that this means that your dependencies, after you 
recompile for 1.5.0, will be "libtiff4" not "tiff".  (I've already taken 
the liberty of updating the setup.hint files in accordance with today's 
*official* release, changing setup.hints from 'tiff' to 'libtiff3' (3 
for the official release; later you'll need to change it to 4 for the 
1.5.0 release.  This affects emacs-X11, WindowMaker, and tetex-bin)

There is one other change in this test release:

* updated to the tiff-v3.6.0beta2 release

--
  Charles Wilson
  cygwin at removespam cwilson dot fastmail dot fm

Re: [Ready for test/1.5.0] gdbm-1.8.3-4, libgdbm4

[Pierre A. Humblet]

At 11:32 PM 7/21/2003 -0400, Charles Wilson wrote:
>Pierre A. Humblet wrote:
>
>
>> 
>> Given that 1.8.3-3 and 1.8.3-4 contain incompatible dlls, isn't the
>> tradition to name the packages differently and have them coexist in
>> setup for a while (without default upgrading when in non-test mode)?
>> 
>> That way old applications can keep working when gdbm is updated
>> and rebuilding the databases is only necessary when the relevant
>> application (exim, cvs,...) is updated to use the new gdbm.
>
>Yes, it is -- and that is what I did.
>
>The old dll was/is named cyggdbm-3.dll and is in the libgdbm3 package. 
>The new dll is named cyggdbm-4.dll and is in the libgdbm4 package.
>
>What's the problem?

None. I didn't know about libgdbm4.

Pierre

Re: [Ready for test/1.5.0] gdbm-1.8.3-4, libgdbm4

[Charles Wilson]

Pierre A. Humblet wrote:


Given that 1.8.3-3 and 1.8.3-4 contain incompatible dlls, isn't the
tradition to name the packages differently and have them coexist in
setup for a while (without default upgrading when in non-test mode)?
That way old applications can keep working when gdbm is updated
and rebuilding the databases is only necessary when the relevant
application (exim, cvs,...) is updated to use the new gdbm.
Yes, it is -- and that is what I did.

The old dll was/is named cyggdbm-3.dll and is in the libgdbm3 package. 
The new dll is named cyggdbm-4.dll and is in the libgdbm4 package.

What's the problem?

--
Chuck

RE: [SetupXP] Issue list

[Gary R. Van Sickle]

> Gary,
>
> Here is a partial list of issues from your mega-patch.
>

I still bristle at the "mega" ;-).  43K including the bulk of res.rc ain't even
*close* to "mega" ;-).

> * Issue: Drop -r HEAD
> Please do this ASAP. If you need further evidence for the desirability of
> this, just look to res.rc, specifically at the way your diff removes my
> multiline comment about "MS Shell Dlg".
>

Dude, I tried to do this, but something happened.  I apologize.  Check it now, I
think it's ok.

> * Issue: LogFile::Exit
> * LogFile.cc (LogFile::exit): Only exit() on error, otherwise return
> to caller.
> * LogFile.h (LogFile::exit): Remove noreturn attribute.
> * LogSingleton.h (LogSingleton::exit): Remove noreturn attribute.
> * main.cc (main): Change some comments.
> Please either revert these changes, or reopen discussion on this topic.
>

I maintain the noreturns should be removed on the basis that:
a. LogXxxx isn't/shouldn't be the long-term program exit() location, hence
they'll have to be removed eventually anyway.
b. They add nothing in the interim except confusion.

> * Issue: PropertyPage::OnInit
> I've suggested a change, and confirmed your understanding of my suggestion
> (PreOnInit), but you haven't said whether you think it is a good or bad
> idea.
>

I'm not sure yet, that's why ;-).  I think it's good, but I'll have to look into
it.

> * Issue: IDD_SPLASH res.rc changes
> * res.rc (IDD_SPLASH): Move icon.  Change commented-out
> "white box" static control to a black invisible one.
> Please either revert these changes, or reopen discussion on this topic.
>

Huh, that is an odd size, wonder why I did that.  Alright, but in return you
have to tell my why you want me to revert all this stuff in my *local* copy;
isn't that why it's local, so's I can play around in my proverbial sandbox?

> * Issue: OnActivate
> I'm leaving the final decision up to Robert, then I will distil a patch
> (unless you want to, in which case, tell me) and submit it for review.
>

I don't want to unless everybody's happy.

> I don't intend to raise any more issues from the patch until most of these
> are taken care of - juggling any more parallel threads of discussion could
> get awkward.
>
>
> Max.
>
>

--
Gary R. Van Sickle
Brewer.  Patriot.

Re: Waiting for xfree86? [Was: guile-1.6.4-1]

[Charles Wilson]

Christopher Faylor wrote:

> On Mon, Jul 21, 2003 at 08:17:44PM +0200, Jan Nieuwenhuizen wrote:
>
>> Christopher Faylor <[EMAIL PROTECTED]> writes:
>>
>>
>>> Why are we waiting for these libraries?  Do they export variables or
>>> functions which rely on new 64 bit types?
>>
>>
>> I haven't investigated that.  It's just that they are listed in:
>>
>> 
http://www.mail-archive.com/[EMAIL PROTECTED]/msg07117.html
>
>
>
> I suspect that Chuck was a little overzealous in listing packages.  As I
> have been saying (and saying, and saying...) there is no need to 
rebuild a
> package unless its interface has changed.

No, I was extremely overzealous -- and said so.  I put EVERYTHING I was 
not sure of into category 5.  I figured it was up to the maintainers, 
not me, to say "waitaminute, my package doesn't export any interfaces 
that changed..."

But I agree, there should probably be another category or subcategory, 
since none of the five I listed really work for this case.

Re: [curr:] guile-1.6.4-1

[Charles Wilson]

Jan Nieuwenhuizen wrote:

> Guile 1.6.4 is available for upload.
>
> Btw, I would have a 1.5.0 version for test: available.  However, as
> lilypond [is the only package that] depends on guile, I think it makes
> sense to upload 1.5.0 versions of both packages together.  But
> lilypond also depends on tetex, and tetex is still waiting for tiff
> and XFree.
I'm moving as fast as I can, here...but a warning about tiff.

tiff depends on jpeg.  And because jpeg had an ABI change (and DLL name 
change), that means that tiff must do so as well.  [think about it, 
you'll see why]

So, my next step is to release an official, split, upgrade for tiff that 
is 1.3.22 compatible.  Then, I will release a test version of tiff for 
1.5.0.  Give me a couple of hours.

--
Chuck

RE: [SetupXP] The two styles for handling activation refusal

[Gary R. Van Sickle]

I'm still letting you guys fight this out, but I'm going to snipe from the
sidelines ;-):

[snip]
> > I do not see "bool OnActivate()" as being confusing, nor as less intuitive
> > that firing 2 event handlers consecutively.
>
> There is only one handler. I'm glad that it wouldn't confuse you though
> :}.
>

It will confuse anybody who is used to how Windows does things.  And semantics
aside, OnAcceptActivate() or whatever you want to rename it is handling a
message from the base class, ergo a message handler.

> > It is true that every instance
> > of OnActivate has to start returning a value, but I don't see this as
> > incorrect.
>
> I do.
>

It's not incorrect, you just don't like it.

> > Quoting Robert:
> > > Changing OnActivates meaning would conflate things in the method, and
> > > make the code harder to read - "what does false mean - that Activate
> > > failed?".
> >
> > I think activating, or deciding not to activate, are tightly bound
> > activities, which *should* be handled together. And yes, false does mean
> > that Activate failed - because the page's internal logic chose to make it
> > happen.
>
> No, it doesn't.
> - failing indicates a /problem/.

Throwing an exception would indicate a problem actually, if you want to get all
by-the-book about it.

> - not being activated indicates the page shouldn't be shown.
>
> mixing the two up is exactly the sort of conflation I was referring to
> as occuring when the two aren't separated. It's ALREADY confused you, as
> your statement above indicates: the Antivirus refusal is /not/ a
> failure.
>
> > Quoting Robert's Pro and Con points:
> > Pro1: * Factor out conflated functionality
> > Pro2: * Step us toward some form of MVC pattern
> > Pro3: * Improve readability
> >
> > Con1: * Add additional logic to an extant method.
> > Con2: * Conflate GUI logic with processing logic.
> > Con3: * Make setup harder to read.
> >
> > Addressing point-by-point:
> >
> > Pro1, Pro3, Con3 : IMO, OnActivate is the logical and intuitive place to put
> > this functionality.
>
> Again, it's not. It's the place a lot of programmers would put it - but
> they would rue it in 6 or 12 months.

...while we argue about it for 6 to 12 months.

> From an OOP point of view, the
> evolution might go something like:
> bool PageFoo:OnActivate() {
>   if (some test)
> return false;
>   ...
>   return true;
> }
>

Nope.  Common case:

bool Whatever::OnActivate()
{
...
return true;
}

> "damn, why do I have to hard code this into every derived page.

A return code.  Please.

> It's
> getting tiresome, and we've had juniors adding pages by copying others
> and leaving inappropriate tests in place.

Which could just as well happen in your preferred scheme Rob, come on.

>We also had some guy throw a
> fatal exception from the parent when activation 'failed' - (s)he didn't
> understand that false isn't a failure. That wasn't that bad though, it
> was when the page they had been working on DID fail, but only returned
> false and left the entire app unstable that we really had to scramble to
> fix things up.
>
> I really need to make it /clear/ that all we are doing is allow the page
> to decide itself whether it can be activated..."
>

"Does the OnAcceptActivate() call happen before or after the call to
OnActivate()?  The normal Windows way is to return a code from OnActivate(), so
it must be after, but..."

We can come up with doomsday scenarios until... well, doomsday... and still not
have a bigger chooser.

>
> > Pro2, Con1: IMO, the extra logic truly belongs here, and any other placement
> > contravenes Pro3, Con3.
>
> Sorry, I don't buy this. It doesn't have anything to do with an MVC
> pattern. Altering the signature DOES add additional logic to an extand
> method, which IS CON1. Saying that the logic /truely/ belongs there
> doesn't alter it invoking con1.
>

I'm getting dizzy from all these ProX's and ConY's.

> > Con2: As a piece of GUI logic, the page class is an appropriate location.
> > If, in the distant future, we gain an interactive text UI, then there would
> > be reason to factor code out into a new style-neutral UI layer - but that's
> > a whole new topic.
>
> We have the skeleton of text processing.

Huh?  An interactive text UI?

> In point of fact , I didn't use
> con2 for this example - I was making a list of general things I
> consider.
>
> > Right, that was my attempt to sell the "bool OnActivate()" style, which I
> > believe to be best. However, I do want something to get into setup *soon*,
> > so, if this hasn't convinced you, Robert, I will set about extracting the
> > minimal set of AcceptActivate() changes from Gary's monster-patch.
>
> It hasn't convinced me. You've asserted your opinion, which I
> understand, but you've not swayed me. You've not demonstrated any
> benefits I hadn't considered, and you seem to miss the long term costs
> that mixing the two functions /will/ incur - even though they have
> already affected you!
>
> I repeat t

Re: TEST: mc-4.6.0a-20030721-1

[Elfyn McBratney]

On Tue, 22 Jul 2003, Pavel Tsekov wrote:

> Please,
> upload:
> http://ptsekov.gamersrevolt.it/cygwin/release/mc/mc-4.6.0a-20030721-1-src.tar.bz2
> http://ptsekov.gamersrevolt.it/cygwin/release/mc/mc-4.6.0a-20030721-1.tar.bz2
> http://ptsekov.gamersrevolt.it/cygwin/release/mc/setup.hint

Done.

-- 
Elfyn McBratney, EMCB  |  http://www.nongnu.org/wwwauth/
http://www.emcb.co.uk  |  http://www.emcb.co.uk/webauth/
[EMAIL PROTECTED]   |  wwwauth-users AT nongnu DOT org

Re: [Ready for test/1.5.0] gdbm-1.8.3-4, libgdbm4

[Pierre A. Humblet]

At 06:11 AM 7/20/2003 -0400, Charles Wilson wrote:

>I've just posted an *official* new release of gdbm to the main list.  I
>reverted my entire system to 1.3.22 status (no test packages at all), and
>rebuilt gdbm with Pierre's programs.  That's the new, curr: release
>(1.8.3-3)
>
>Then, I moved forward again to all-testing-1.5.0, and put this package
>together (1.8.3-4).
>
>I bumped the DLL version number, so the two DLLs (cyggdbm-3.dll and
>cyggdbm-4.dll) can both coexist.  So un-recompiled programs that rely on
>gdbm (like cvs!) will continue to work with the -3 dll and all will be
>well.

Given that 1.8.3-3 and 1.8.3-4 contain incompatible dlls, isn't the
tradition to name the packages differently and have them coexist in
setup for a while (without default upgrading when in non-test mode)?

That way old applications can keep working when gdbm is updated
and rebuilding the databases is only necessary when the relevant
application (exim, cvs,...) is updated to use the new gdbm.

Pierre

Possible setup bug: downloading wrong src packages

[Pavel Tsekov]

Robb, Sam wrote:

> It looks like setup.exe is downloading the wrong source
> packages if a package has a "test" entry in setup.ini.

> You can confirm this by doing a default installation,
> setting the installation type to "Download from Internet",
> and asking setup to download the source package for
> zlib-1.1.4-1 (for example).

I saw a similiar thing today. I wanted to install the gettext-devel _BINARY_
package.
I failed to select the Exp radio button and instead I just used the category
window
to cycle trough the different version for gettext-devel. Each time I ended
up with
libgettextpo package being selected for installation i.e. when I went to the
partial 
view I could see libgettextpo selected for installtion. My setup is
2.340.2.5.

Btw I recall that in the past I've reported some kind of setup misbehaviour 
in conjunction
with _SOURCE_ packages. Unfortunately I don't have any other recollections
anymore.

Pavel

-- 
+++ GMX - Mail, Messaging & more  http://www.gmx.net +++

Jetzt ein- oder umsteigen und USB-Speicheruhr als Prämie sichern!

TEST: mc-4.6.0a-20030721-1

[Pavel Tsekov]

Hello,

I've prepared the 64-bit test version of Midnight Commander. I took the
opportunity to
update the codebase from CVS since it has been almost 5 months since 4.6.0
was
released.

It seems that the internal viewer (invoked by pressing F3) causes a crash
inside the
guts of Cygwin, when used on large (multigigabyte) files. The crash occures
in the
memory allocation routines and seems like it has nothing to do with the new
64-bit stuff.
I'm trying to track it problem down. In the meanwhile this version should be
good enough
for general testing of the 64-bit capabilities. I'll put a note in the
announcement about that.

Please,
upload:
http://ptsekov.gamersrevolt.it/cygwin/release/mc/mc-4.6.0a-20030721-1-src.tar.bz2
http://ptsekov.gamersrevolt.it/cygwin/release/mc/mc-4.6.0a-20030721-1.tar.bz2
http://ptsekov.gamersrevolt.it/cygwin/release/mc/setup.hint

Thanks!

Pavel

-- 
+++ GMX - Mail, Messaging & more  http://www.gmx.net +++

Jetzt ein- oder umsteigen und USB-Speicheruhr als Prämie sichern!

RE: Possible setup bug: downloading wrong src packages

[Robb, Sam]

> Can you confirm this:
> delete your setup.log and setup.log.full.
> run with the latest snapshot, and then post:
> your setup.log 
> setup.log.full
> the setup.ini's that setup placed in the directory cache with the
> mistmatched tarballs..

Gladly.  Still see the same behavior with setup-2.364.

The files you requested were tar'd up, gzip'd, and are
attached.

-Samrobb


setup-files.tar.bz2
Description: setup-files.tar.bz2

Re: Possible setup bug: downloading wrong src packages

[Elfyn McBratney]

On Mon, 22 Jul 2003, Robert Collins wrote:

> On Tue, 2003-07-22 at 06:27, Robb, Sam wrote:
> > It looks like setup.exe is downloading the wrong source
> > packages if a package has a "test" entry in setup.ini.
> >
> > You can confirm this by doing a default installation,
> > setting the installation type to "Download from Internet",
> > and asking setup to download the source package for
> > zlib-1.1.4-1 (for example).
>
> Can you confirm this:
> delete your setup.log and setup.log.full.
> run with the latest snapshot, and then post:
> your setup.log
> setup.log.full
> the setup.ini's that setup placed in the directory cache with the
> mistmatched tarballs..

I've been downloading 'src' packages for (nearly) all test packages that have
been released and haven't come accross this (with latest stable setup) version
mismatch. Just for clarity, I tried with the latest snapshot (2.364) too, and
I get the same behaviour...it works as it should.

Elfyn

-- 
Elfyn McBratney, EMCB  |  http://www.nongnu.org/wwwauth/
http://www.emcb.co.uk  |  http://www.emcb.co.uk/webauth/
[EMAIL PROTECTED]   |  wwwauth-users AT nongnu DOT org

Re: Possible setup bug: downloading wrong src packages

[Robert Collins]

On Tue, 2003-07-22 at 06:27, Robb, Sam wrote:
> It looks like setup.exe is downloading the wrong source
> packages if a package has a "test" entry in setup.ini.
> 
> You can confirm this by doing a default installation,
> setting the installation type to "Download from Internet",
> and asking setup to download the source package for
> zlib-1.1.4-1 (for example).

Can you confirm this:
delete your setup.log and setup.log.full.
run with the latest snapshot, and then post:
your setup.log 
setup.log.full
the setup.ini's that setup placed in the directory cache with the
mistmatched tarballs..

Rob
-- 
GPG key available at: .


signature.asc
Description: This is a digitally signed message part

Possible setup bug: downloading wrong src packages

[Robb, Sam]

It looks like setup.exe is downloading the wrong source
packages if a package has a "test" entry in setup.ini.

You can confirm this by doing a default installation,
setting the installation type to "Download from Internet",
and asking setup to download the source package for
zlib-1.1.4-1 (for example).

When the download is finished, you will find mismatched
packages in the release/zlib directory:

  zlib-1.1.4-1.tar.bz2
  zlib-1.1.4-2-src.tar.bz2

I can provide a setup.log ans setup.log.full if anyone
cares to take a look at them, though a quick examination
doesn't seem to show anything obviously wrong.

-Samrobb

Re: [SetupXP] The two styles for handling activation refusal

[Robert Collins]

On Tue, 2003-07-22 at 00:02, Max Bowsher wrote:
> OK, this is a general reply to multiple messages.
> 
> I still believe "bool OnActivate()" to be the better option - here's why:
> 
> The "if(canActivate()){OnActivate()}" scheme makes 2 method calls where only
> one is required.

Premature optimisation. Activation occurs what - 8 times in a typical
run?

>  It also opens the possibility for OnActivate to be called
> when activation is not desired. The top of each OnActivate has to grow an
> "if (!canActivate) return;", or trust its caller not to do something
> incorrect.

Sure it has to Note that this is:
a) A Template Method. (All event handlers are Template Methods in a
general sense). Template Methods depend on the parent Doing The Right
Thing.
b) The exception case - most pages don't care and will always activate.
c) worthy of a 1-line comment above the virtual event handler :
  /* Only called if canActivate() returns true */

Make the common case easy, the exception harder.

> I do not see "bool OnActivate()" as being confusing, nor as less intuitive
> that firing 2 event handlers consecutively. 

There is only one handler. I'm glad that it wouldn't confuse you though
:}.

> It is true that every instance
> of OnActivate has to start returning a value, but I don't see this as
> incorrect.

I do.

> Quoting Robert:
> > Changing OnActivates meaning would conflate things in the method, and
> > make the code harder to read - "what does false mean - that Activate
> > failed?".
> 
> I think activating, or deciding not to activate, are tightly bound
> activities, which *should* be handled together. And yes, false does mean
> that Activate failed - because the page's internal logic chose to make it
> happen.

No, it doesn't.
- failing indicates a /problem/.
- not being activated indicates the page shouldn't be shown.

mixing the two up is exactly the sort of conflation I was referring to
as occuring when the two aren't separated. It's ALREADY confused you, as
your statement above indicates: the Antivirus refusal is /not/ a
failure.

> Quoting Robert's Pro and Con points:
> Pro1: * Factor out conflated functionality
> Pro2: * Step us toward some form of MVC pattern
> Pro3: * Improve readability
> 
> Con1: * Add additional logic to an extant method.
> Con2: * Conflate GUI logic with processing logic.
> Con3: * Make setup harder to read.
> 
> Addressing point-by-point:
> 
> Pro1, Pro3, Con3 : IMO, OnActivate is the logical and intuitive place to put
> this functionality.

Again, it's not. It's the place a lot of programmers would put it - but
they would rue it in 6 or 12 months. From an OOP point of view, the
evolution might go something like:
bool PageFoo:OnActivate() {
  if (some test)
return false;
  ...
  return true;
}

"damn, why do I have to hard code this into every derived page. It's
getting tiresome, and we've had juniors adding pages by copying others
and leaving inappropriate tests in place. We also had some guy throw a
fatal exception from the parent when activation 'failed' - (s)he didn't
understand that false isn't a failure. That wasn't that bad though, it
was when the page they had been working on DID fail, but only returned
false and left the entire app unstable that we really had to scramble to
fix things up.

I really need to make it /clear/ that all we are doing is allow the page
to decide itself whether it can be activated..."


> Pro2, Con1: IMO, the extra logic truly belongs here, and any other placement
> contravenes Pro3, Con3.

Sorry, I don't buy this. It doesn't have anything to do with an MVC
pattern. Altering the signature DOES add additional logic to an extand
method, which IS CON1. Saying that the logic /truely/ belongs there
doesn't alter it invoking con1.

> Con2: As a piece of GUI logic, the page class is an appropriate location.
> If, in the distant future, we gain an interactive text UI, then there would
> be reason to factor code out into a new style-neutral UI layer - but that's
> a whole new topic.

We have the skeleton of text processing. In point of fact , I didn't use
con2 for this example - I was making a list of general things I
consider.

> Right, that was my attempt to sell the "bool OnActivate()" style, which I
> believe to be best. However, I do want something to get into setup *soon*,
> so, if this hasn't convinced you, Robert, I will set about extracting the
> minimal set of AcceptActivate() changes from Gary's monster-patch.

It hasn't convinced me. You've asserted your opinion, which I
understand, but you've not swayed me. You've not demonstrated any
benefits I hadn't considered, and you seem to miss the long term costs
that mixing the two functions /will/ incur - even though they have
already affected you!

I repeat the ruling I gave Gary some moons ago:
Use a query method. It's appropriate, less code, easier to adapt in the
future, and a cleaner design.

Rob

-- 
GPG key available at: .


signature.as

Re: Waiting for xfree86? [Was: guile-1.6.4-1]

[Christopher Faylor]

On Mon, Jul 21, 2003 at 08:17:44PM +0200, Jan Nieuwenhuizen wrote:
>Christopher Faylor <[EMAIL PROTECTED]> writes:
>
>> Why are we waiting for these libraries?  Do they export variables or
>> functions which rely on new 64 bit types?
>
>I haven't investigated that.  It's just that they are listed in:
>
>http://www.mail-archive.com/[EMAIL PROTECTED]/msg07117.html

I suspect that Chuck was a little overzealous in listing packages.  As I
have been saying (and saying, and saying...) there is no need to rebuild a
package unless its interface has changed.

cgf

Re: Waiting for xfree86? [Was: guile-1.6.4-1]

[Jan Nieuwenhuizen]

Christopher Faylor <[EMAIL PROTECTED]> writes:

> Why are we waiting for these libraries?  Do they export variables or
> functions which rely on new 64 bit types?

I haven't investigated that.  It's just that they are listed in:

http://www.mail-archive.com/[EMAIL PROTECTED]/msg07117.html

as class 5:

So, there are really five classes of packages:

1) already recompiled for 1.5.0
2) non-binary
3) binary, but not for new use (e.g. could be recompiled, but why?)
4) empty compatibility packages (newlib-man, texmf?)
5) need to be recompiled 1.5.0

So I figured that a package that needs to be recompiled, would export
new symbols.  But maybe class 5 should be split:

5a: need to be recompiled, but does not export new 64 bit types
(no need to wait for this)
5b: need to be recompiled, exports 64 bit types.  packages with
requires: should wait for this to be recompiled

I've been very busy off late, and only learned about 1.5 a few days ago.

Jan.

-- 
Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien   | http://www.lilypond.org

Re: Waiting for xfree86? [Was: guile-1.6.4-1]

[Christopher Faylor]

On Mon, Jul 21, 2003 at 06:48:35PM +0200, Jan Nieuwenhuizen wrote:
>Corinna Vinschen <[EMAIL PROTECTED]> writes:
>
>> > I think it makes sense to upload 1.5.0 versions of both packages
>> > together.  But lilypond also depends on tetex, and tetex is still
>> > waiting for tiff and XFree.
>> 
>> That's a problem since Harold decided to wait for 1.5.0 becoming the
>> official release before moving XFree over.
>
>Then what to do with packages that depend on X libraries such as
>tetex-x11.  Do we really need to make special X-less release, ie,
>rebuild tetex and ghostscript without X11 first?

Why are we waiting for these libraries?  Do they export variables or
functions which rely on new 64 bit types?

cgf

Waiting for XFree86? [Was: guile-1.6.4-1]

[Jan Nieuwenhuizen]

Corinna Vinschen <[EMAIL PROTECTED]> writes:

> > I think it makes sense to upload 1.5.0 versions of both packages
> > together.  But lilypond also depends on tetex, and tetex is still
> > waiting for tiff and XFree.
> 
> That's a problem since Harold decided to wait for 1.5.0 becoming the
> official release before moving XFree over.

Then what to do with packages that depend on X libraries such as
tetex-x11.  Do we really need to make special X-less release, ie,
rebuild tetex and ghostscript without X11 first?

Jan.

-- 
Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien   | http://www.lilypond.org

Re: [curr:] guile-1.6.4-1

[Corinna Vinschen]

On Mon, Jul 21, 2003 at 04:14:43PM +0200, Jan Nieuwenhuizen wrote:
> Guile 1.6.4 is available for upload.
> 
> Btw, I would have a 1.5.0 version for test: available.  However, as
> lilypond [is the only package that] depends on guile, I think it makes
> sense to upload 1.5.0 versions of both packages together.  But
> lilypond also depends on tetex, and tetex is still waiting for tiff
> and XFree.

That's a problem since Harold decided to wait for 1.5.0 becoming the
official release before moving XFree over.  Unless we can't find a
volunteer...

> http://lilypond.org/cygwin/uploads/guile/setup.hint
> 
> sdesc: "The GNU extension language and Scheme interpreter (executable)"
> category: interpreters
> # Strictly, guile does not depend on readline and curses, but if you
> # want the guile executable, you probably want readline editing.  -- jcn
> requires: cygwin libguile12 libncurses6 libreadline5
  ^^^
  Shouldn't that be libncurses7?

Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Developermailto:[EMAIL PROTECTED]
Red Hat, Inc.

[SetupXP] Issue list

[Max Bowsher]

Gary,

Here is a partial list of issues from your mega-patch.

* Issue: Drop -r HEAD
Please do this ASAP. If you need further evidence for the desirability of
this, just look to res.rc, specifically at the way your diff removes my
multiline comment about "MS Shell Dlg".

* Issue: LogFile::Exit
* LogFile.cc (LogFile::exit): Only exit() on error, otherwise return
to caller.
* LogFile.h (LogFile::exit): Remove noreturn attribute.
* LogSingleton.h (LogSingleton::exit): Remove noreturn attribute.
* main.cc (main): Change some comments.
Please either revert these changes, or reopen discussion on this topic.

* Issue: PropertyPage::OnInit
I've suggested a change, and confirmed your understanding of my suggestion
(PreOnInit), but you haven't said whether you think it is a good or bad
idea.

* Issue: IDD_SPLASH res.rc changes
* res.rc (IDD_SPLASH): Move icon.  Change commented-out
"white box" static control to a black invisible one.
Please either revert these changes, or reopen discussion on this topic.

* Issue: OnActivate
I'm leaving the final decision up to Robert, then I will distil a patch
(unless you want to, in which case, tell me) and submit it for review.

I don't intend to raise any more issues from the patch until most of these
are taken care of - juggling any more parallel threads of discussion could
get awkward.


Max.

Re: [SetupXP] The two styles for handling activation refusal

[Max Bowsher]

Gary R. Van Sickle wrote:
> I'll do my best to get something up yet tonight.  Again though Max, please
> keep in mind that I posted the SetupXP stuff mainly so people could try
out
> the now-proven-to-not-work-right XP theme feature, not because I had loads
of
> time to get back on the bigger/resizable[1] chooser stuff.

That actually works out well, since it is better that you don't write more
code until we've merged your extant changes.

All you need to do is explain motivations for changes when that is not
clear, and keep "cvs update"ing, reverting changes from your local copy, and
reposting your diff regularly (feel free to not update the tarball as
regularly, if bandwidth is an issue).

> [1] Yep, I'm making some headway on the resizability stuff now.  It will
be
> glorious!

Indeed it will!

Max.

Re: [SetupXP] The two styles for handling activation refusal

[Max Bowsher]

OK, this is a general reply to multiple messages.

I still believe "bool OnActivate()" to be the better option - here's why:

The "if(canActivate()){OnActivate()}" scheme makes 2 method calls where only
one is required. It also opens the possibility for OnActivate to be called
when activation is not desired. The top of each OnActivate has to grow an
"if (!canActivate) return;", or trust its caller not to do something
incorrect.

I do not see "bool OnActivate()" as being confusing, nor as less intuitive
that firing 2 event handlers consecutively. It is true that every instance
of OnActivate has to start returning a value, but I don't see this as
incorrect.

Quoting Robert:
> Changing OnActivates meaning would conflate things in the method, and
> make the code harder to read - "what does false mean - that Activate
> failed?".

I think activating, or deciding not to activate, are tightly bound
activities, which *should* be handled together. And yes, false does mean
that Activate failed - because the page's internal logic chose to make it
happen.

Quoting Robert's Pro and Con points:
Pro1: * Factor out conflated functionality
Pro2: * Step us toward some form of MVC pattern
Pro3: * Improve readability

Con1: * Add additional logic to an extant method.
Con2: * Conflate GUI logic with processing logic.
Con3: * Make setup harder to read.

Addressing point-by-point:

Pro1, Pro3, Con3 : IMO, OnActivate is the logical and intuitive place to put
this functionality.

Pro2, Con1: IMO, the extra logic truly belongs here, and any other placement
contravenes Pro3, Con3.

Con2: As a piece of GUI logic, the page class is an appropriate location.
If, in the distant future, we gain an interactive text UI, then there would
be reason to factor code out into a new style-neutral UI layer - but that's
a whole new topic.


Right, that was my attempt to sell the "bool OnActivate()" style, which I
believe to be best. However, I do want something to get into setup *soon*,
so, if this hasn't convinced you, Robert, I will set about extracting the
minimal set of AcceptActivate() changes from Gary's monster-patch.

Max.

[curr:] guile-1.6.4-1

[Jan Nieuwenhuizen]

Guile 1.6.4 is available for upload.

Btw, I would have a 1.5.0 version for test: available.  However, as
lilypond [is the only package that] depends on guile, I think it makes
sense to upload 1.5.0 versions of both packages together.  But
lilypond also depends on tetex, and tetex is still waiting for tiff
and XFree.

Jan.


http://lilypond.org/cygwin/uploads/guile/setup.hint

sdesc: "The GNU extension language and Scheme interpreter (executable)"
category: interpreters
# Strictly, guile does not depend on readline and curses, but if you
# want the guile executable, you probably want readline editing.  -- jcn
requires: cygwin libguile12 libncurses6 libreadline5
ldesc: "The GNU extension language and Scheme interpreter (executable)
Guile, the GNU Ubiquitous Intelligent Language for Extension, is a scheme
implementation designed for real world programming, supporting a
rich Unix interface, a module system, and undergoing rapid development.
`guile' is a scheme interpreter that can execute scheme scripts (with a
#! line at the top of the file), or run as an inferior scheme
process inside Emacs."

http://lilypond.org/cygwin/uploads/guile/guile-1.6.4-1-src.tar.bz2
http://lilypond.org/cygwin/uploads/guile/guile-1.6.4-1.tar.bz2

===

http://lilypond.org/cygwin/uploads/guile/guile-devel/setup.hint

sdesc: "Development headers and static libraries for Guile."
category: devel libs
requires: cygwin guile libguile12
external-source: guile
ldesc: "Development headers and static libraries for Guile.
`libguile.h' etc. C headers, aclocal macros, the `guile-snarf' and
`guile-config' utilities, and static `libguile.a' libraries for Guile,
the GNU Ubiquitous Intelligent Language for Extension."

http://lilypond.org/cygwin/uploads/guile/guile-devel/guile-devel-1.6.4-1.tar.bz2

===

http://lilypond.org/cygwin/uploads/guile/guile-doc/setup.hint

sdesc: "The GNU extension language and Scheme interpreter (documentation)"
category: doc
requires: texinfo
external-source: guile
ldesc: "The GNU extension language and Scheme interpreter (documentation)
This package contains the documentation for guile, including both
a reference manual (via `info guile'), and a tutorial (via `info
guile-tut')."

http://lilypond.org/cygwin/uploads/guile/guile-doc/guile-doc-1.6.4-1.tar.bz2

===

http://lilypond.org/cygwin/uploads/guile/libguile12/setup.hint

sdesc: "The GNU extension language and Scheme interpreter (runtime libraries)"
category: libs
requires: cygwin libltdl3
external-source: guile
ldesc: "The GNU extension language and Scheme interpreter (runtime libraries)
Guile shared object libraries and the ice-9 scheme module.  Guile is
the GNU Ubiquitous Intelligent Language for Extension."

http://lilypond.org/cygwin/uploads/guile/libguile12/libguile12-1.6.4-1.tar.bz2

===


-- 
Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien   | http://www.lilypond.org

TEST: which-1.5-2

[Corinna Vinschen]

Hi,

I've uploaded the 64 bit version of which, 1.5-2, marked as "test".

Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Developermailto:[EMAIL PROTECTED]
Red Hat, Inc.

TEST: patch-2.5.8-4

[Corinna Vinschen]

Hi,

I've uploaded the 64 bit version of patch, 2.5.8-4, marked as "test".

Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Developermailto:[EMAIL PROTECTED]
Red Hat, Inc.

TEST: login-1.9-6

[Corinna Vinschen]

Hi,

I've uploaded the 64 bit version of login, 1.9-6, marked as "test".

Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Developermailto:[EMAIL PROTECTED]
Red Hat, Inc.

Re: Pending package status (20 Jul 2003)

[Gareth Pearce]

Trying to find out everything thats been happening ... my hotmail clogged up
and a whole stack of email didnt get delivered - somewhat of a mess.  It
even deleted some of my older emails - annoying. - in future i'll not keep
any old emails around in hotmail :)

> I'd rather let Gareth take a look at these first before they're put up as
> "available" - he's the maintainer, after all :)

i rebuilt from source package - and things look good. (except i forgot to
install ncurses first so ... i had the funny buggy letter thing again)
>
> So the canonical versions of the Cygwin packages should (IMHO) be
> considered the versions Gareth provided - at least until he canonicalizes
> mine.
I'd say they look fine.

Regards,
Gareth

RE: [SetupXP] The two styles for handling activation refusal

[Robert Collins]

On Mon, 2003-07-21 at 15:25, Gary R. Van Sickle wrote:

> Well, my current code appears to work if changed to do that.  But then
> OnAcceptActivate() is equivalent to my original return value changes (i.e. just
> leave OnActivate() empty and OnAcceptActivate() is your message handler).

Maybe I'm not being clear.
OnAcceptActivate should be -exactly- one line.

bool AntiVirusPage::OnAcceptActivate() {
  return KnownAVspresent;
}

OnAcceptActivate is not intended to be, and never will be a message handler. 


> I'm not sure that this whole thing doesn't set an ugly precedent.  Do we do this
> for *every* message coming down the pipe?
> 
> if(OnAreYouGoingToDoAnythingInDraw())
> {
>   OnDraw();
> }

No, as there is a fundamental difference between the two:
  deciding to be 'unavilable' for activation changes the user interface
- the driver needs to move onto the next dialog.
  skipping drawing does not.

Rob
-- 
GPG key available at: .


signature.asc
Description: This is a digitally signed message part

Re: Pending package status (20 Jul 2003)

[Ronald Landheer-Cieslak]

> @ Aspell
> 
> date   : 07 Apr 2003
> version: 0.50.3-1
> status : reviewed (downloads for 1.5 only)
> notes  : http://cygwin.com/ml/cygwin-apps/2003-04/msg00155.html
>  http://cygwin.com/ml/cygwin-apps/2003-04/msg00356.html
>  http://cygwin.com/ml/cygwin-apps/2003-06/msg00239.html
>  http://cygwin.com/ml/cygwin-apps/2003-07/msg00319.html
> reviews: http://cygwin.com/ml/cygwin-apps/2003-07/msg00222.html
>  http://cygwin.com/ml/cygwin-apps/2003-07/msg00332.html
> votes  : 4 (Christopher, Elfyn, Gerrit and Igor)
> url: http://blytkerchan.chez.tiscali.fr/aspell-0.50.3-1-src.tar.bz2
>  http://blytkerchan.chez.tiscali.fr/aspell-0.50.3-1.tar.bz2
>  http://blytkerchan.chez.tiscali.fr/aspell-0.50.3-1.tar.bz2
>  http://blytkerchan.chez.tiscali.fr/aspell-dev-0.50.3-1.tar.bz2
>  http://blytkerchan.chez.tiscali.fr/aspell-doc-0.50.3-1.tar.bz2
>  http://blytkerchan.chez.tiscali.fr/libaspell15-0.50.3-1.tar.bz2
>  http://blytkerchan.chez.tiscali.fr/aspell-bin.setup.hint
>  http://blytkerchan.chez.tiscali.fr/aspell-dev.setup.hint
>  http://blytkerchan.chez.tiscali.fr/aspell-doc.setup.hint
>  http://blytkerchan.chez.tiscali.fr/libaspell15.setup.hint
I'd rather lket Gareth take a look at these first before they're put up as 
"available" - he's the maintainer, after all :)

So the canonical versions of the Cygwin packages should (IMHO) be 
considered the versions Gareth provided - at least until he canonicalizes 
mine.

rlc

RE: [SetupXP] The two styles for handling activation refusal

[Robert Collins]

On Mon, 2003-07-21 at 17:32, Morrison, John wrote:


> Would...
> 
> if (canActivate())
>   OnActivate()
> 
> be better? (although the OnXXX functions always make me think that
> they should be callbacks.)

Yes - I was simply leaving method names alone until I had an answer on
the ordering breaking [or not] anything.

alternatives - canShow(), okToDisplay() ... etc.

Rob
-- 
GPG key available at: .


signature.asc
Description: This is a digitally signed message part

RE: [SetupXP] The two styles for handling activation refusal

[Morrison, John]

Robert Collins wrote:
> On Mon, 2003-07-21 at 04:17, Gary R. Van Sickle wrote:
> 
>>> Unless there will ever be a need to ask a page whether
>>> it would take activation in the future, but not activate it
>>> immediately, even if it is possible to do so, I think the 2 calls
>>> should be merged. Will there ever be such a case?
>> 
>> I cannot think of one.  It exists soley to give OnActivate a
>> "default return code".  It *can't* be called anywhere else, since in
>> the general case, OnAcceptActivation won't know if it needs to
>> refuse activation until after OnAccept is called.
> 
> Hmm. My intention when I suggested a query method was for it to be
> called *instead* of OnActivate, and OnActivate only called if it
> returned true. 
> 
> Will doing that break anything?
> 
> For clarity:
> if (OnAcceptActivate())
>   OnActivate()

Hi guys :)

Would...

if (canActivate())
OnActivate()

be better? (although the OnXXX functions always make me think that
they should be callbacks.)

J.


===
Information in this email and any attachments are confidential, and may
not be copied or used by anyone other than the addressee, nor disclosed
to any third party without our permission.  There is no intention to
create any legally binding contract or other commitment through the use
of this email.
Experian Limited (registration number 653331).
Registered office: Talbot House, Talbot Street, Nottingham NG1 5HF

Re: 1.5.0 Test packages status (issue 2)

[Marcel Telka]

On 2003.07.17 09:16, Charles Wilson wrote:
1) already recompiled for 1.5.0
2) non-binary
3) binary, but not for new use (e.g. could be recompiled, but why?)
4) empty compatibility packages (newlib-man, texmf?)
5) need to be recompiled 1.5.0



NEED TO BE RECOMPILED FOR 1.5.0
---
[...]

docbook-xml42
docbook-xsl
Please move both docbook-xml42 and docbook-xsl to #2. They are not 
compiled... Thanks.

--
+---+
| Marcel Telka   e-mail:   [EMAIL PROTECTED]  |
|homepage: http://telka.sk/ |
|jabber:   [EMAIL PROTECTED] |
+---+