Re: ghostscript 6.51-4 now ready
Dario Alcocer wrote: > I've finished testing and packaging the latest release of Ghostscript; > the new release uses the libpng and zlib shared libraries, as > suggested by Chuck Wilson. I've put the packages and MD5 sum file at: > > http://members.cox.net/dalcocer/gs > > If someone has upload capability to sources.redhat.com and can upload > this package, please let me know. I'll wait until the package has > been uploaded before I post my package update announcement. > > Thanks in advance, Uploaded. --Chuck
Re: setup.exe rebase patch
Robert Collins wrote: > >>-Original Message- >>From: Christopher Faylor [mailto:[EMAIL PROTECTED]] >> > >>However, I agree that rebasing shouldn't be the default >>behavior. In fact, I wonder if I should make cygwin >>non-rebaseable. It would load faster if I did that. >> > > Yes, and it would solve some of the nasty faults -auto-image-base. (The strange >behaviour of often choosing a base that collides with cygwin). > > Rob > Note: libtool-devel does not use auto-image-base. I don't THINK libtool-stable does, either. And all of "my" DLLs have been rebuilt over the last several months without auto-image-base. Just FYI. Also, there was some code passed back and forth a while ago (Rob, yours maybe?) that purported to add a "non-relocatable" option to binutils. I don't remember the specifics, but I think there were some problems with that particular implementation. A working version that added a "non-relocatable" option to ld when creating a DLL would be a nice addition to binutils. Anybody remember more about this? I'm drawing a blank... --Chuck
RE: setup.exe rebase patch
> -Original Message- > From: Christopher Faylor [mailto:[EMAIL PROTECTED]] > However, I agree that rebasing shouldn't be the default > behavior. In fact, I wonder if I should make cygwin > non-rebaseable. It would load faster if I did that. Yes, and it would solve some of the nasty faults -auto-image-base. (The strange behaviour of often choosing a base that collides with cygwin). Rob
Re: setup.exe rebase patch
On Tue, Feb 26, 2002 at 09:49:01PM -0500, Charles Wilson wrote: >Jason Tishler wrote: > > >>>(Or do you rebase cygwin1.dll as well :]]). >>> >> >>Yes, I can rebase cygwin1.dll too. This is why I converted the >>stand-alone rebase to a Mingw app. > > >Urk. If we follow Earnie's suggestion to include the output of 'objdump >-S1' with cygwin1.dlll snapshots and the (main)cygwin package, then >rebasing cygwin1.dll will break that. Seems like rebasing cygwin1.dll >itself should never be the default behavior... > >http://cygwin.com/ml/cygwin-developers/2002-02/msg00029.html I suppose that if we were really clever we could detect where cygwin was offset to and readjust the symbol file accordingly as needed. However, I agree that rebasing shouldn't be the default behavior. In fact, I wonder if I should make cygwin non-rebaseable. It would load faster if I did that. cgf
Re: setup.exe rebase patch
Jason Tishler wrote: >>(Or do you rebase cygwin1.dll as well :]]). >> > > Yes, I can rebase cygwin1.dll too. This is why I converted the > stand-alone rebase to a Mingw app. Urk. If we follow Earnie's suggestion to include the output of 'objdump -S1' with cygwin1.dlll snapshots and the (main)cygwin package, then rebasing cygwin1.dll will break that. Seems like rebasing cygwin1.dll itself should never be the default behavior... http://cygwin.com/ml/cygwin-developers/2002-02/msg00029.html --Chuck
ghostscript 6.51-4 now ready
I've finished testing and packaging the latest release of Ghostscript; the new release uses the libpng and zlib shared libraries, as suggested by Chuck Wilson. I've put the packages and MD5 sum file at: http://members.cox.net/dalcocer/gs If someone has upload capability to sources.redhat.com and can upload this package, please let me know. I'll wait until the package has been uploaded before I post my package update announcement. Thanks in advance, -- Dario Alcocer -- Sr. Software Developer, Helix Digital Inc. [EMAIL PROTECTED] -- http://www.helixdigital.com
Re: setup.exe rebase patch
On Tue, Feb 26, 2002 at 04:26:53PM -0500, Jason Tishler wrote: 10) Please capitalise the first letter of words in class names. Setup has been quite haphazard, I'm trying to be more consistent :}. Also, I prefer things like FreeList to free_list - I find them easier. >>> >>>The above made me smile! I completely agree with you. However, I was >>>just trying to follow the GNU coding style. Specifically, the >>>following item is relevant here: >>> >>>http://www.gnu.org/prep/standards_26.html#SEC26 >> >>Erk. Well I use VI :]. cinstall isn't a Gnu Project, and I've always >>taken the standards as guidelines rather than godlines. > >Since Cygwin follows the GNU coding style, I just assumed that >setup.exe did too. Well, I do consider cinstall a cygwin project so I would hope that we do adhere to GNU coding style as much as possible. I really don't want too much variation. However, since it's C++, I don't think that the coding standard really is 100% appropriate, so let Rob's Rules Prevail. cgf
Re: setup.exe rebase patch
Rob, On Tue, Feb 26, 2002 at 09:54:37AM +1100, Robert Collins wrote: > - Original Message - > From: "Jason Tishler" <[EMAIL PROTECTED]> > > I guess that I was trying to ask a more philosophical question of how > > coupled rebase was going to be with setup.exe. It sounds like you are > > comfortable with a tight coupling. Is this correct? > > Yes. I think that setup.exe based rebasing should be optional, but > default to on. A flag in rebase.conf to control this would be good, > along with a dialogue box and a tick :]. Not needed for the initial > merge though. OK, sounds good. I'm not a GUI guy -- I hope that Gary will come to my rescue. :,) > > I haven't tried LoadLibrary(), etc. but I presume that one of the > > APIs can. However, isn't this too little, too late? What can we do > > when the corruption occurs? Rollback to the copy in the archive? > > But, then this image will *not* be rebased. :,( > > I was thinking of the following process (for all dlls we attempt to > rebase): > 0) Check that it hasn't been rebased already. What is the purpose of the above? I already rebase DLLs into their previous space during reinstalls, if they still fit. > 1) Copy > 2) Rebase > 3) Check for corruption - mark as occupying it's own prior space if > corrupt and then stop, otherwise mark it's new space in the used list. What happens when the prior space is already taken? > We can yes, it's certainly not urgent. My concept rough concept on the > process was that rebasing would be moved out of the install routines > (because uninstalls free up used list space) and be made to occur after > all the files have been installed, we'd have a complete list of .dll's > that need may rebasing, and whose dependents should be checked at the > same time. Is the "complete list" approach above required for the first iteration? > (Or do you rebase cygwin1.dll as well :]]). Yes, I can rebase cygwin1.dll too. This is why I converted the stand-alone rebase to a Mingw app. > > > 1) log.cc - don't clean up there. If you need to cleanup, have a > > > static object whose destructor should get called. > > > > This is already done too (see rebaser.cc:338). Note that my > > stand-alone rebase.exe is already using this successfully. > > Gotcha, ok the log.cc call should go then - or does this introduce sife > effects? Currently, the config file won't be saved. This won't be a problem once the config file is saved as soon as the installation phase is finished. > > > 2) I really don't like the rebaser::set_cygwin_root_dir construct: > > > why not use get_root_dir () when you need the cygwin root? (Any > > > why do you need it? Surely you only need cygpath (filename) ? > > > > This is for the stand-alone case which I wasn't sure was going to be > > able to easily share code with setup.exe. This concern appears to > > be mitigated. I can certainly have rebaser always retrieve the Cygwin > > root from the registry if this is deemed the better approach. > > Ah. Well within setup io_stream is the answer as they Huh? You didn't finish the above sentence. > > I tried to find the appropriate abstractions in the problem domain. > > I tried to encapsulate implementations behind reasonable interfaces to > > minimize the impact of implementations changes. Etc, etc. However, > > I'm open to design changes too, if deemed necessary. > > What feels procedural is separate classes for serialisation. I _feel_ > (And can there for be told to get my nose out of it) that a better > encapsulation would be for the used list and free list to have > [de]serialisation capability, and the config_file class to shrink to > simply finding the config file, identifying the beginning of (say) a > used list section, and then passing the buck. Would you care to comment > on this as opposed to your current model? Ah, I see your point. I guess that it depends on how you want to slice and dice. I have used the load/save paradigm many times before and in general prefer it. However, in this case I don't quite think of the config file data as object state. What happens if there are syntax errors, etc.? I think that a config file object should deal with these kinds of issues (although is could delegate some of the responsibility to the list objects). Additionally, with my current approach I can change the config file format without affecting the list classes. Nevertheless, if you feel strongly, then I will change my perspective. > > > 9) Should we rename my 'list.h' to 'vector.h' > > > > vector does seem to better capture the semantics. But, what is the > > relevance to my list code? Are you suggesting that I use your stuff. > > I tried but I needed STL map-like functionality. > > I'm suggesting I get my stuff out of your way :}. Your code seems > traditional list based, which mine isn't (anymore), so your code could > generalise to be a list/map template. OK, sounds good. > > > 10) Please capitalise the first letter of words in class
Re: New textutils
On Tue, Feb 26, 2002 at 12:14:03AM -0600, Matthew Smith wrote: > Hi, could someone please upload the following packages for me? The > setup.hint that's there should be fine. > > http://www.bluesguitar.org/~matts/textutils-2.0.21-1.tar.bz2 > http://www.bluesguitar.org/~matts/textutils-2.0.21-1-src.tar.bz2 Done. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc.
