Re: Gitflow proposal

[Matt Rice]

I think Fred hits the major points quite well,

in all the GNU projects i've ever worked on besides GNUstep even
maintainers post patches for review for the benefit of other
maintainers.  Certain things are disqualified from this, such as
fixing typos, unbreaking master either by reverting or fixing the
commit... Things which could be justified as being obvious changes.

Generally when patches are posted, and do not receive review a
maintainer (usually the author but i don't feel like ruling it out),
can give a heads up that they intend to commit the patch in the near
future within some reasonable timeframe...

This adds a bit of delay to the whole process however not entirely
unbounded nor too rigid,
but gives others their say.  Personally i would say the lack of any
review process was a major factor in my decision to stop
contributing...

On Fri, Nov 15, 2019 at 8:16 AM Fred Kiefer  wrote:
>
> First off before I explain why I am strongly against Gitflow let me restate 
> that I advocate feature branches and pull requests. But I will come back to 
> that in the end.
>
> A software workflow should match the organisation and purpose of a project 
> and the people that defined Gitflow are well aware of that. They describe 
> what sort of projects Gitflow is suited for. GNUstep does not meet that 
> criteria. Even in the place where I work we decided against Gitflow as it is 
> not well suited for our processes. I could go into details here but I believe 
> you are all able to follow the link below and read the description.
>
> Also it won’t work. Nobody is getting payed to review pull requests on 
> GNUstep. If I started to write pull requests for GNUstep gun, they would be 
> sitting there for a year or so without anybody noticing.
>
> The bigger problem is that even Gitflow won’t help us with our quality 
> issues. Over the last few months I have tried to provide comments to most of 
> the pull requests in the GNUstep repository. I do this a lot at work and 
> doing so comes naturally to me. Most of the developers react positive by 
> fixing the issues I point to. There is one exception and please look it up in 
> git to see the difference. In that case many of my comments did get ignored 
> others, where flagged as done although no change was made and sometimes 
> branches where merged even when travis reported them as broken or while I had 
> objected merging them. So even a workflow that enforces all this is of no use 
> in this case.
>
> And it could be even worse. With Gitflow in place as a rule, Riccardo and I 
> could have been stopped from doing the emergency fixes we did last night to 
> get master compiling again (and not only for gcc, Riccardo's change must have 
> fixed compilation of clang as well). As long as we have rogue developers with 
> full permissions out there, we need ways to counteract.
>
> So yes, let's use more branches and pull requests but especially those 
> developers that break the build. And if we ever manage to get them to follow 
> that rules we might start to think about more process.
>
> Fred
>
> > Am 15.11.2019 um 05:30 schrieb Gregory Casamento :
> >
> > Guys,
> >
> > I must say this.  I have been trying to, in general, hold myself to doing 
> > this rather formally up until recently.  I admit that I have been more 
> > directly pushing things in as of late.
> >
> > Since, as you say, this could have been avoided by doing PRs... which it 
> > could have.  Should we not, as an project, move to this model?  It's known 
> > as gitflow and it's what I was following when I would create a branch with 
> > large changes and then have it reviewed by yourself and others before 
> > merging.   This would slow some development down, but it would have the 
> > effect of keeping master in a condition where it always builds and is 
> > always releasable (which should always be the case).
> >
> > Here is a link, for reference: 
> > https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
> >
> > Some might argue that this should only be done with large teams, but I used 
> > this process on a small team when I worked at a company known as customink 
> > where we only had 4 people and it still helped things go very smoothly.
> >
> > This is the process I've been trying to adhere to.  I would advocate that, 
> > if PRs could have prevented this then, perhaps, we should all move to it.  
> > I had a discussion with Riccardo where he thought this process was too much 
> > and was silly and that merging to the master branch directly is always the 
> > best way to go.   That's precisely what caused this.   We can make all of 
> > the arguments that "a focused developer wouldn't make these mistakes" but 
> > that's BS.  Process is here to prevent mistakes or to mitigate them.
> >
> > I disagree with Riccardo's position wholeheartedly.   A more controlled and 
> > disciplined approach should be adopted and we should stick to it.
> >
> > Any thoughts?
> >
> > Yours, GC
>

Re: Segmentation Faults - OpenBSD

[Matt Rice]

Fred, did you try on OpenBSD?

This smells to me like an issue of relying upon the platform dependent
shared library constructor call order.

perhaps the innocuous looking NSBundle changes here:
https://github.com/gnustep/libs-base/commit/43673452a505a79a55dd1d59b0789f5ebc2eec0c#diff-c09284bb3ef153ed33bb7f447c4fe88e

such as perhaps: NSBundle +load -> +initialize, and perhaps
GSTinyString's +load or some such being called in an unexpected order.
anyhow, the setName: call should result in a memcpy... perhaps
Riccardo could give it a go without that change.



On Fri, Mar 30, 2018 at 11:10 AM, Fred Kiefer  wrote:
> I tried to reproduce this error but failed. Either it is a local problem on 
> your machine or it was already fixed. Could you please try again?
>
> Fred
>
>> Am 30.03.2018 um 00:53 schrieb Riccardo Mottola :
>>
>> Hi All,
>>
>> After updating GNUstep on OpenBSD/i386 with gcc, I noticed that all 
>> applications segfault. At first, I thought it is a strange combination of an 
>> old setup, with system gcc+libobjc1 (which however worked before upgrading)
>> However, I have a second machine where GS was proven working and with gcc 
>> 4.9 and its own runtime, a setup that worked before and worked on other 
>> system.
>> Test: everything works, update, gnustep base, gui, back : everything 
>> segfaults! so that machine is the proof that the commits of the past week 
>> broke,
>> I don't see how OpenBSD can be so much different, it worked for a long time.
>>
>> I notice that during gui build:
>>
>> Making all for service GSspell...
>> gmake[4]: Nothing to be done for 'internal-service-compile'.
>> Creating GSspell.service/Resources/Info-gnustep.plist...
>> Segmentation fault (core dumped)
>> gmake[3]: *** 
>> [/usr/GNUstep/System/Library/Makefiles/Instance/service.make:141: 
>> GSspell.service/Resources/Info-gnustep.plist] Error 1
>>
>> so I found that something as simple as this:
>> $ plparse Source/Info-gnustep.plist
>> Segmentation fault (core dumped)
>>
>> this smells as an issue in base! doesn't it?
>>
>> this even more:
>> $ plparse
>> Segmentation fault (core dumped)
>>
>> however, this is of no use at all!!
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x0cfd6dbc in _libc_memcpy (dst0=0x38c, src0=0x7b41c0bc, length=2031685792)
>>at /usr/src/lib/libc/string/memcpy.c:54
>> 54  /usr/src/lib/libc/string/memcpy.c: No such file or directory.
>>in /usr/src/lib/libc/string/memcpy.c
>> Current language:  auto; currently minimal
>>
>>
>> so now? even id I build with debug, I get no better stacktrace. This sounds 
>> bad,
>>
>>
>> Riccardo
>>
>>
>>
>> ___
>> Gnustep-dev mailing list
>> Gnustep-dev@gnu.org
>> https://lists.gnu.org/mailman/listinfo/gnustep-dev
>
>
> ___
> Gnustep-dev mailing list
> Gnustep-dev@gnu.org
> https://lists.gnu.org/mailman/listinfo/gnustep-dev

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Confusion in instructions on sending fixes in "reporting bugs" webpage

[Matt Rice]

I would change it something to the effect of:
"When submitting via a mailing list include your ChangeLog entry in
the contents of your email rather than in the diff."

On Sun, Oct 29, 2017 at 7:46 AM, Ivan Vučica  wrote:
> http://www.gnustep.org/developers/bugs.html
>
> Quoting:
>
> """
> Sending fixes
> Actually fixing problems is even more appreciated than sending in bug
> reports. To do this, first fix the bug and make sure it works. Then send in
> a diff file containing the differences between the old version of the
> file(s) you changed and the new version. Use the diff (diff -u) program to
> do this. Then add a ChangeLog entry in front of this and send the whole
> thing to bug-gnus...@gnu.org.
>
> If you use emacs, it is easy to add a ChangeLog entry. Just edit the file
> you changed, and move the cursor to the function or method you changed, then
> type
>
> M-x add-change-log-entry
> and emacs automatically formats an entry in the ChangeLog file with the
> information on the file and function you changed. You just need to add a
> comment about what was fixed. Note: Don't send a diff of the ChangeLog file,
> just send a copy of your ChangeLog entry normally. Here is an example
> ChangeLog:
>
> 
> """
>
> (1) I think I am subscribed to bug-gnustep@. I don't recall receiving any
> patches recently that way. I think it's still okay to suggest this mailing
> list, as long as we're aware of it.
> (2) This is the actual reason why I'm sending this email: """Note: Don't
> send a diff of the ChangeLog file""". This has been interpreted by a
> contributor as "Don't include ChangeLog in your commits", which is
> technically accurate (as commits are not much more than patches), but
> creates extra burden on the maintainer.
>
> I'd suggest removing this sentence; whether the patch is submitted over
> email or through some contribution management system (e.g. one that allows
> pull requests), I think it's better to request contributors to update
> ChangeLog entries than not, because then the maintainer needs to come up
> with a change.
>
> This is the practice which we had for Google Summer of Code.
>
> This may have made some vague sense in the world of Subversion or CVS or
> patch-via-email, but right now it's just creating overhead.
>
> Can we strike it out, or at the very least say "This only applies when
> you're contributing via a mailing list, and not when you are contributing
> otherwise"?
>
> ___
> Gnustep-dev mailing list
> Gnustep-dev@gnu.org
> https://lists.gnu.org/mailman/listinfo/gnustep-dev
>

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: linking a C++ lib to an objc tool.

[Matt Rice]

Another question is, which libraries is it finding at link time,
it could be that e.g. the file exists but is of the wrong architecture
(in which case i forget what happens)
but adding LDFLAGS=-Wl,--verbose should print out which library is
being linked against
(It may be easiest to just make messages=yes then copy/paste add
-Wl,--verbose to the link command, I at least don't remember the
correct gnustep-make variable to use)

also note that openapp sources a GNUstep.sh

On Sun, Sep 3, 2017 at 11:20 AM, Ivan Vučica  wrote:
> "of course it does" <== Hm. I would say that, given your system dynamic
> loader seems to refuse to ... uh ... "dlopen()"[1] the file, the existence
> of /home/jamie/Developer/System/lib/libgnustep-base.so.1.24 is far from
> given -- that is, I don't think the expression "of course" is appropriate in
> this situation.
>
> Yes, by 'Can you open it?' I meant 'can you read it any other process, under
> the same conditions as the WindowServer process experiences when started'
> (conditions such as what is the running user of the process, for example).
>
> Either way, it's now totally unclear to me why the dynamic loader would find
> the file, then skip it. Maybe someone else has a better idea. If the file is
> there, and it's readable, it smells of a possible dynamic loader bug. Or
> perhaps the distribution you're using has an obscure security feature
> preventing dlopen()-equivalent from the homedir. Both situations would be
> very strange to me, and I doubt that's what is happening. *shrug*
>
> I doubt you did this, but does the WindowServer binary have setuid / setgid
> bits set on it? LD_LIBRARY_PATH does not work in that case.
>
> While this should not be relevant in a sane environment and if your binary's
> file does not have setuid/setgid bits, can you check if you can still
> reproduce the problem if you don't install GNUstep into your homedir?
>
>
>
> Either way, I do not think this is a GNUstep issue? It seems like a deeper
> issue with your system's dynamic loader.
>
> [1]: Let's call it dlopen() for simplicity.
>
> On Sun, Sep 3, 2017 at 12:54 PM Jamie Ramone  wrote:
>>
>> Yes, of course it does. Open...how? You mean being able to view it's
>> contents in mcedit? Yes.
>>
>> On Sun, Sep 3, 2017 at 7:36 AM, Ivan Vučica  wrote:
>>>
>>> Let's go back :)
>>>
>>> Does /home/jamie/Developer/System/lib/libgnustep-base.so.1.24 exist? Can
>>> you open it?
>>>
>>>
>>> On Sun, Sep 3, 2017, 11:30 Jamie Ramone  wrote:

 Well, isn't this an interesting turn of events! So I tried your (Ivan's)
 idea of looking at what the linker's doing when the binary is run. This is
 the output:
  19216:
  19216: file=libpoppler-cpp.so.0 [0];  needed by
 Source/obj/WindowServer [0]
  19216: find library=libpoppler-cpp.so.0 [0]; searching
  19216:  search
 path=/home/jamie/Developer/System/lib/tls/x86_64:/home/jamie/Developer/System/lib/tls:/home/jamie/Developer/System/lib/x86_64:/home/jamie/Developer/System/lib
 (LD_LIBRARY_PATH)
  19216:   trying
 file=/home/jamie/Developer/System/lib/tls/x86_64/libpoppler-cpp.so.0
  19216:   trying
 file=/home/jamie/Developer/System/lib/tls/libpoppler-cpp.so.0
  19216:   trying
 file=/home/jamie/Developer/System/lib/x86_64/libpoppler-cpp.so.0
  19216:   trying
 file=/home/jamie/Developer/System/lib/libpoppler-cpp.so.0
  19216:
  19216: file=libpoppler-cpp.so.0 [0];  generating link map
  19216:   dynamic: 0x7f8f1c191d78  base: 0x7f8f1bf8
 size: 0x002125d8
  19216: entry: 0x7f8f1bf885e0  phdr: 0x7f8f1bf80040
 phnum:  7
  19216:
  19216:
  19216: file=libgnustep-base.so.1.24 [0];  needed by
 Source/obj/WindowServer [0]
  19216: find library=libgnustep-base.so.1.24 [0]; searching
  19216:  search path=/home/jamie/Developer/System/lib
 (LD_LIBRARY_PATH)
  19216:   trying
 file=/home/jamie/Developer/System/lib/libgnustep-base.so.1.24
  19216:  search cache=/etc/ld.so.cache
  19216:  search
 path=/lib/x86_64-linux-gnu/tls/x86_64:/lib/x86_64-linux-gnu/tls:/lib/x86_64-linux-gnu/x86_64:/lib/x86_64-linux-gnu:/usr/lib/x86_64-linux-gnu/tls/x86_64:/usr/lib/x86_64-linux-gnu/tls:/usr/lib/x86_64-linux-gnu/x86_64:/usr/lib/x86_64-linux-gnu:/lib/tls/x86_64:/lib/tls:/lib/x86_64:/lib:/usr/lib/tls/x86_64:/usr/lib/tls:/usr/lib/x86_64:/usr/lib
 (system search path) 19216:   trying
 file=/lib/x86_64-linux-gnu/tls/x86_64/libgnustep-base.so.1.24
  19216:   trying
 file=/lib/x86_64-linux-gnu/tls/libgnustep-base.so.1.24
  19216:   trying
 file=/lib/x86_64-linux-gnu/x86_64/libgnustep-base.so.1.24
  19216:   trying
 

Re: corebase: use __builtin___CFStringMakeConstantString when available?

[Matt Rice]

It doesn't look like that would work as is,

neither of the gnu ld's appear to support the -alias_list argument, It
appears to have only been brought up once on the list afaict,

having not looked into it very much at all, the solution in that
thread may work for what you are doing as well...

https://sourceware.org/ml/binutils/2009-11/msg00329.html

On Wed, Jul 12, 2017 at 11:31 AM, Daniel Ferreira (theiostream)
 wrote:
> I was just browsing swift-corelibs-foundation by accident (to see
> something totally unrelated) and I just ran into how it solves the
> issue. It uses a linker feature I did not even know existed to use a
> "symbol alias list". It does exactly what I'd wondered if it were
> possible – mapping an actual class symbol (their "NSCFConstantString")
> into __CFConstantStringClassReference.
>
> It passes `-Wl,-alias_list,SymbolAliases` to the linker, and
> `SymbolAliases` contains
> https://github.com/apple/swift-corelibs-foundation/blob/19249417b01573bd6aa32b9a24cc42273315a48b/CoreFoundation/Base.subproj/SymbolAliases#L4.
>
> Any change CoreBase could make use of this?
>
> -- Daniel.
>
> On Wed, Jun 28, 2017 at 9:30 AM, Stefan Bidigaray  
> wrote:
>> Hi Daniel, I guess I should throw my 2 cents in as I know the hacks I had to
>> do in CoreBase in order to get constant CFStrings.
>>
>> The files of interest will be Source/GSPrivate.h and
>> Source/CFConstantString.c in the CoreBase sources.
>>
>> GSPrivate.h defined a macro called CONST_STRING_DECL() that creates a
>> constant string structure with the *isa = NULL. CoreBase is able to deal
>> with the *isa pointer being NULL, but not it being a pointer to a structure
>> that is "malformed".
>>
>> At runtime, it mimics I had to mimic what the libobjc's did and assign the
>> correct *isa for each string. This requires having a complete list of all
>> constant strings and initializing them one-by-one at library load time. This
>> is done in CFConstantString.c. The CFConstantStringInitialize() function is
>> called by CFInitialize() when the library is loaded. I thought about doing
>> what you're suggesting, somehow making a point to _OBJC_CLASS_* structures,
>> but that ended up being a dead-end and not worth pursuing.
>>
>> Unfortunately, I had to make CoreBase somewhat dependent on various
>> implementation details, for many reasons. In this case, library load times
>> are important, since libobjc and -base need to be up and running before
>> CFConstantStringIntialize() is called. The problem with using
>> __builtin_CFStringMakeConstantString() is that it is equivalent to @"", and
>> this was a problem for me at the time because it would cause the toll-free
>> bridging mechanism to be constant called, unnecessarily.
>>
>> As you'll quickly see, all this stuff is private to CoreBase, so you'd
>> either have to expose this functionality or come up with your own constant
>> string solution. I wouldn't have a problem exposing it, even though I would
>> rather keep my messy hacks "private".
>>
>> I think I should also mention that there is nothing in CoreBase that makes
>> it inherently dependent on -base or libobjc. At the time I was still
>> actively working on CoreBase, the need arose for a pure-C base library that
>> was familiar to me. Since I had already done some work with GNUstep and
>> understood the paradigms it made sense to make this so. That was around the
>> time I reimplemented all the toll-free bridged CF-types in C instead of
>> relying on -base's implementations. By modifying the makefile, you can still
>> built a pure-C version on CoreBase, by the way. I'd like to keep it that
>> way.
>>
>> Hope this helps! And I apologize for taking so long to reply to your email.
>>
>> Regards
>> Stefan
>>
>> On Tue, Jun 27, 2017 at 8:19 PM, Daniel Ferreira (theiostream)
>>  wrote:
>>>
>>> Hmm, bad news about this.
>>>
>>> Here's the commit that enables this feature on CoreBase, for some
>>> context on what I'll discuss next:
>>>
>>> https://github.com/theiostream/corebase/commit/98d799a6de056f1b99fa9a218a0f354f613ba578.
>>>
>>> Sadly, simply switching CFSTR() from __CFStringMakeConstantString() to
>>> __builtin___CFStringMakeConstantString() doesn't just work
>>> out-of-the-box. Both clang and gcc generate, out of that builtin, a
>>> struct that "fits" into CFStringRef's spec, but there is one tricky
>>> detail. Its "isa" member is set on compile-time to a pointer tracked
>>> by the __CFConstantStringClassReference symbol.
>>>
>>> The symbol itself would not be a problem. We could just point it on
>>> compile-time to null bytes and pretend that never existed (as Apple
>>> seems to do on CFLite). But CoreBase totally relies on that "isa"
>>> member having something meaningful, and it'll pretty much always
>>> forward that null "isa" to libobjc2 to try to figure out the CFType of
>>> that constant string. This broken "isa" will crash libobjc2.
>>>
>>> That said, I need a way to place a 

Re: Problem installing bundles without GNUSTEP_INSTALLATION_DIR

[Matt Rice]

FWIW, I always found pmanager http://gna.org/projects/pmanager
to have a much more sane architecture than PC...
it hasn't seen activity in a long time however...

Additionally for bundles there is the foo_COPY_INTO_DIR...
you can see it used here

https://github.com/gnustep/gdl2/blob/master/EOAdaptors/PostgreSQLAdaptor/LoginPanel/GNUmakefile

On Sat, Jan 21, 2017 at 2:10 PM, Jamie Ramone  wrote:
> Hmm, it seems PC DOESN'T clobber the GNUMakefile.pre- and post-amble.
> So basically yeah, this approach works! :) But I know u can't do
> anything to the main make file. It uses the PC.project file to
> generate it and happily stomps all over any change you've made to that
> one. I just had to manually edit out a stale file reference from the
> PC.project file just to be able to compile the project again as it
> failed to recognize a name change and included that reference into the
> makefile, borking all compilations...ProjectCenter is a dick sometimes
> is what I'm saying :-/ What other ideas did you have.
>
> On Sat, Jan 21, 2017 at 1:04 PM, Ivan Vučica  wrote:
>> If it generates the lines that include GNUmakefile.postamble, you can use
>> that to patch up ProjectCenter-generated makefiles.
>>
>> Exactly which targets you should use, I don't know without looking closer.
>>
>> Also, someone else may have better ideas.
>>
>> On January 21, 2017 12:22:55 AM GMT+00:00, Jamie Ramone
>>  wrote:
>>>
>>> How do u mean, using one of those *:: targets (like after-all::), or
>>> are u talking about another means? I wouldn't have a problem with that
>>> but PC f@*#ing does whatever it wants to the make files. I'm beginning
>>> to manage to coax it into doing what I want by poking around in the
>>> .PC files. I'll give it a try.
>>>
>>> On Fri, Jan 20, 2017 at 7:40 PM, Ivan Vučica  wrote:

  I don't know the capabilities of ProjectCenter, but if you use makefiles
  directly, it could be rather easy to copy the bundle in "manually".


  On Fri, Jan 20, 2017, 21:50 Jamie Ramone  wrote:
>
>
>  Hi steppers, me again. So here's the deal: I built a modular
>  application thru the use of bundles and the app searches several paths
>  obtained from the domains upon start up, and can manually add them
>  later on if a valid bundle is dropped on the app (not implemented yet
>  tho). Any way, the thing is some modules are meant to be included
>  inside the app's bundle, but I can't find a way to get the bundles
>  included there upon building the app in ProjectCenter. Can this be
>  done at all? I mean in an automated way, other than manually copying
>  the module bundle into the app bundle itself. Thanx!
>
> 
>
>  Discuss-gnustep mailing list
>  discuss-gnus...@gnu.org
>  https://lists.gnu.org/mailman/listinfo/discuss-gnustep
>>
>>
>> --
>> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>
> ___
> Discuss-gnustep mailing list
> discuss-gnus...@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnustep

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Authors.txt file for GIT migration...

[Matt Rice]

On Tue, Mar 1, 2016 at 8:30 PM, Gregory Casamento
 wrote:
> Hey guys,
>
> I am using the attached file as the authors file for git migration.   If any
> of you remember any of these handles, please add the email and name.  There
> are a few which are not filled in.   There are also about 5 IDs which are
> not currently identified.  Presumably because those people have removed
> their accounts from gna.
>
> Anyway.  Please review the existing file and add what you need to it.  I'm
> wondering if it might not be a bad idea to put it on svn / git so we can
> just commit changes to it, but we are not at that point just yet.
>

If we look at:
http://cvs.savannah.gnu.org/viewvc/gnustep/dgs/tiff/ChangeLog?root=gnustep=log

and the commit by 'netcrep'
http://cvs.savannah.gnu.org/viewvc/gnustep/dgs/tiff/ChangeLog?root=gnustep=1.1=1.2

it has Scott Christley in the ChangeLog
it looks like the scottc account started committing to that directory
a year later, so maybe he just switched usernames?

i haven't managed to track down commits by the 'netc' user

from the other things (particularly uid...) it is difficult to say
without the context of the stuff they committed, and potentially cross
referencing that with list postings.

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Floating point rounding errors in NSTableView?

[Matt Rice]

On Mon, Jun 29, 2015 at 8:07 AM, David Chisnall thera...@sucs.org wrote:
 Hi all,

 I have an application that uses an NSTableView to display a CPU trace.  After 
 about 10,000,000 rows, it’s quite obvious that something is wrong with the 
 rendering - about every 15 rows, there’s a blank line between adjacent rows.  
 By around 15,000,000 it looks as if there’s a blank line between every other 
 line, and some rows are drawn on top of each other.

 By row 100,000,000, every row in a group (height *1.5ish?) is drawn on top of 
 each other one.

 It looks as if there is some floating point rounding happening that’s causing 
 the offset calculation to go wrong?

 David

 P.S. On OS X, the display does not have these problems, though OS X’s 
 NSTableView gets very confused by input events when you scroll beyond about 
 row 100,000,000...

is it apparent in the return value of -[NSTableView rectOfRow:] for
the afflicted rows? _rowHeight contributing to the rect.origin.y seems
to be a float rather than CGFloat?

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Proposal: Switch back to savannah using GIT

[Matt Rice]

On Fri, May 29, 2015 at 1:55 AM, Gregory Casamento
greg.casame...@gmail.com wrote:
 If the consensus is to move to github, then that work is basically already
 done.   The github mirror is a full mirror of all of the code in subversion.
 I agree with David.  Where we are hosted is extremely important since it has
 everything to do with visibility.

 The only problem I am seeing with moving is that we may lose some existing
 contributors or, at least, piss off some existing contributors if we do make
 a move to github.   Additionally, as one might predict, the FSF doesn't like
 github.   So a move to github not only amounts to a move of repos, but I'm
 afraid it's also the equivalent of a fork which is not something I'm opposed
 to talking about.

I tend to side with the FSF in this regard, so I'd prefer something
like gitlab which provides hosting, as well as a free software license
to the software they use to host...

similarly it might not be a bad idea to provide a dns alias to e.g.
git.gnustep.org to whomever is chosen to host, though I suppose
encryption complicates the matter...

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Proposal: Switch back to savannah using GIT

[Matt Rice]

Some people can't justify hosting their sources at a 3rd party,
it may not impact GNUstep as a project, but in theory one could modify
the software to allow synchronizing bug reports (they may have this
already I haven't looked)

I wouldn't say savannah is obscure, it just (cant figure out a way to
say it politely) sucks probably as a result of being understaffed,

anyway I prefer gitlab because a) it doesn't suck, b) it at least
provides free software

popularity contests aren't really a priority to me,
github just happened to be the first to this particular race
just stating my preference feel free to have a different one...

On Fri, May 29, 2015 at 3:47 AM, Gregory Casamento
greg.casame...@gmail.com wrote:
 So, something even more obscure than savannah?

 On Fri, May 29, 2015 at 6:46 AM Matt Rice ratm...@gmail.com wrote:

 On Fri, May 29, 2015 at 1:55 AM, Gregory Casamento
 greg.casame...@gmail.com wrote:
  If the consensus is to move to github, then that work is basically
  already
  done.   The github mirror is a full mirror of all of the code in
  subversion.
  I agree with David.  Where we are hosted is extremely important since it
  has
  everything to do with visibility.
 
  The only problem I am seeing with moving is that we may lose some
  existing
  contributors or, at least, piss off some existing contributors if we do
  make
  a move to github.   Additionally, as one might predict, the FSF doesn't
  like
  github.   So a move to github not only amounts to a move of repos, but
  I'm
  afraid it's also the equivalent of a fork which is not something I'm
  opposed
  to talking about.

 I tend to side with the FSF in this regard, so I'd prefer something
 like gitlab which provides hosting, as well as a free software license
 to the software they use to host...

 similarly it might not be a bad idea to provide a dns alias to e.g.
 git.gnustep.org to whomever is chosen to host, though I suppose
 encryption complicates the matter...

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Proposal: Switch back to savannah using GIT

[Matt Rice]

On Fri, May 29, 2015 at 1:22 AM, David Chisnall thera...@sucs.org wrote:

 - Automatic tarball generation.  When I’m packaging a project for FreeBSD, it 
 makes me very happy to learn that it’s hosted on GitHub, because if I know 
 the release branch name or hash I can automatically generate a URL that is a 
 tarball of the sources and tell the port to grab that for building.  When I’m 
 doing a release of something GitHub-hosted, then it’s trivial: create a tag 
 and you’re done.  We’ve recently moved the public CHERI repo to GitHub 
 precisely because it’s the easiest way of generating tarballs from a repo.

I think one issue with this is that the tags can change,
see this stack overflow question on how to do this is not exactly unpopular

http://stackoverflow.com/questions/8044583/how-can-i-move-a-tag-on-a-git-branch-to-a-different-commit

I think it's always better to rely on the hash rather than an upstream tag
which gives you some flexibility for how to handle it when you do
inevitably run into a case where someone does switch tags on you.

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: problems debugging with clang 3.2, gdb 7.6, libobjc2 SVN, and Ubuntu 13.10

[Matt Rice]

On Mon, Oct 7, 2013 at 12:41 AM, David Chisnall
david.chisn...@cl.cam.ac.uk wrote:

 Yes, the debugger needs to know how to look up the ivar offsets and currently 
 gdb doesn't know how to do that.  I'll hopefully add support for our ABI to 
 LLDB soon, now that the Linux / FreeBSD ports are in an approximately useable 
 state.

 If you want to inspect ivars in the debugger currently, you should use the 
 runtime's introspection functions rather than -.

FWIW, for gdb as well as the above, the most recent round of modern
GNU runtime changes which neutered the Object class, have stopped
gdb's objective-c testsuite from compiling.   The gdb testsuite
probably needs to include its own root class now since there is
apparently no method to allocate an Object.  This would be needed to
test the above changes or could be done separately without the above
changes.

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: problems debugging with clang 3.2, gdb 7.6, libobjc2 SVN, and Ubuntu 13.10

[Matt Rice]

On Fri, Oct 4, 2013 at 3:43 PM, Ivan Vučica ivuc...@gmail.com wrote:
 On 4. 10. 2013., at 21:50, Eric Wasylishen ewasylis...@gmail.com wrote:


 2. Printing ivars is broken. gdb seems to print  self-isa when you do 
 print someivar or print self-someivar. lldb-3.2 prints an error asking 
 you to report a bug.

 I configured gnustep-make with --enable-debug-by-default 
 --enable-objc-nonfragile-abi,  gnustep-base with --disable-mixedabi.

 I talked to Alex S. on Étoilé IRC and he observed the same two problems on a 
 similar setup as me; Quentin also mentioned the ivar printing problem to me.


 I've also had similar problem with printing Objective-C variables on Ubuntu 
 12.04, and whatever-gdb-ships-with-12-04. I think my install has a post-3.2 
 clang SVN, possibly post-3.3. I would suspect it's an incompatibility between 
 libobjc2 and gdb/lldb, though it would be strange if David didn't see it.

don't recall seeing any changes for gdb to support non-fragile ivars,
that'd be my guess

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Archiving tests...

[Matt Rice]

On Fri, Mar 22, 2013 at 12:58 PM, Gregory Casamento
greg.casame...@gmail.com wrote:

 I've been wondering if it might not be possible to build a testing framework
 based on NSEvent so that GUI tests could be scripted instead of manually
 performed, but that's just a thought at the moment.

I did something like this a long time ago, using a plugin to write
events, and a modified backend to replay them,
the main impediment to it working was that NSMenu or something went
and got the current mouse cursor position from the backend, outside of
NSEvent... I recall there being a comment somewhere that the event
queue was 'too slow or out of date'.
so presumably one would have to override that method in the backend as
well as NSEvent (or something...)

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: 64bit changes to gui

[Matt Rice]

On 2/17/13, Richard Frith-Macdonald rich...@tiptree.demon.co.uk wrote:

 On 17 Feb 2013, at 11:33, Fred Kiefer wrote:

 Now that I am almost through with the changes to CGFloat, NSInteger and
 NSUInteger in gui I realized that I did not think about coding. When the
 size of an instance variable changes from int to NSInteger what should
 happen to the coding/decoding code? Lets take the tag of an NSControl as
 the example. The old -initWithCoder: code may look something like this:

  [aDecoder decodeValueOfObjCType: @encode(int) at: _tag];

 Now _tag no longer is an int, is now is an NSInteger. Will that code still
 work?
 Should we change it to @encode(NSInteger)? (I think that is was base did)
 But that will be something different depending on the machine the code
 runs on? Is the coding mechanism able to handle that? And will this work
 for CGFloat as well? And what about old archives, e.g. Gorm files?

 For the last batches of changes I no longer changed the types of the
 instance variables. That is a valid workaround, but only delays the
 decision what to do. Using local variables of the old type for
 coding/decoding would also work, but again looks wrong to me.

 NSArchive/NSUnarchiver is supposed to cope with size differences between
 architectures automatically, but I'm not sure it will cope with different
 types without objecting (though I guess, if it doesn't,  we could make it do
 so).
 That is, if we encode a 32bit int on one machine, it's ok to decode it as a
 64bit int, and if we encode a 64bit int, we can decode it as a 32bit int (as
 long as the original value can fit in a 32bit variable).

FWIW i remember adding some tests for this basictypes.m IIRC
Not sure if they've been updated for NSInteger and friends.

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Multiple _OBJC_Module in the same shared library/framework, not so good

[Matt Rice]

On Wed, Jan 4, 2012 at 2:26 PM, David Chisnall thera...@sucs.org wrote:

 There is no such thing as gcc ld.  There are two GNU linkers, gold and bfd ld.

I believe that the bfd linker also uses the same plugin API and now
supports lto, haven't tried it myself though.

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

[patch] corebase/pyobjc

[Matt Rice]

here's a patch containing the stuff I had to do to corebase to get it
working here without frobing the shared library link order...
Index: objc_interface.h
===
--- objc_interface.h	(revision 33793)
+++ objc_interface.h	(working copy)
@@ -28,7 +28,7 @@
 #define __OBJC_INTERFACE_H__ 1
 
 #include CoreFoundation/CFRuntime.h
-#include GNUstepBase/preface.h
+#include objc/runtime.h
 
 
 
Index: NSCFType.m
===
--- NSCFType.m	(revision 33793)
+++ NSCFType.m	(working copy)
@@ -43,11 +43,6 @@
 
 @implementation NSCFType
 
-+ (void) load
-{
-  CFInitialize();
-}
-
 - (id) retain
 {
   return (id)CFRetain(self);
Index: CFRuntime.m
===
--- CFRuntime.m	(revision 33793)
+++ CFRuntime.m	(working copy)
@@ -379,7 +379,7 @@
 extern void CFTimeZoneInitialize (void);
 extern void CFUUIDInitialize (void);
 
-void CFInitialize (void)
+void __attribute__((constructor(65535))) CFInitialize (void)
 {
   // Initialize CFRuntimeClassTable
   __CFRuntimeClassTable = (CFRuntimeClass **) calloc (__CFRuntimeClassTableSize,
Index: CFUUID.c
===
--- CFUUID.c	(revision 33793)
+++ CFUUID.c	(working copy)
@@ -28,6 +28,7 @@
 #include CoreFoundation/CFBase.h
 #include CoreFoundation/CFString.h
 #include CoreFoundation/CFUUID.h
+#include objc/runtime.h
 
 /* Some of the code in CFUUID is based on Etoile's ETUUID class.
Copyright (C) 2007 Yen-Ju Check yjchenx AT gmail DOT com */
Index: CFBase.m
===
--- CFBase.m	(revision 33793)
+++ CFBase.m	(working copy)
@@ -250,7 +250,8 @@
 void CFNullInitialize (void)
 {
   _kCFNullTypeID = _CFRuntimeRegisterClass (CFNullClass);
-  ((CFRuntimeBase*)kCFNull)-_isa = [NSNull class];
+  /* don't use [NSNull class] before autorelease pool setup. */
+  ((CFRuntimeBase*)kCFNull)-_isa = objc_getClass(NSNull);
 }
 
 CFTypeID
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: [patch] corebase/pyobjc

[Matt Rice]

On Mon, Aug 29, 2011 at 3:19 PM, Matt Rice ratm...@gmail.com wrote:
 here's a patch containing the stuff I had to do to corebase to get it
 working here without frobing the shared library link order...


I should explain the NSNull change.. gnustep tries to warn me that my
libobjc sucks (isn't thread safe) with NSLog which autoreleases a ton
of stuff, which segfaults.

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: [patch] corebase/pyobjc

[Matt Rice]

On Mon, Aug 29, 2011 at 3:26 PM, Stefan Bidi stefanb...@gmail.com wrote:
 The NSNull change looks fine.  I figured that was the case, I just generally
 do not get the segfault with missing autorelease pools just the warnings.

 The only question I have is about the change to CFUUID.c.  Why are you
 including objc/runtime.h there?  That's not even a bridged class, so
 shouldn't need any interaction with objc runtime.

forgot reply to all, for BOOL/YES/NO

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: [patch] corebase/pyobjc

[Matt Rice]

bah... so the __attribute__((constructor)) thing doesn't really
work it appears to have done _something_,

apparently i'm told constructor priorities aren't supposed to work
across shared library boundries...

and the effect that I got when using that priority was that it
inverted my constructor calling order relative to what it was
before...

thus: it matched what David/Ludvoic were using... but it is still link
order dependent.  This seems like a linker bug..

again, (irrelevent because of the shared library thing), but i'm told
that if constructors with priorities are supposed to be called before
constructors without priorities.

anyhow, you may just want to drop that portion of the patch and/or see
if it inverted David/Ludovic's call order in which case we're back to
square 1

otherwise maybe there is a way to lazily initialize these values as
they are needed.

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: [patch] corebase/pyobjc

[Matt Rice]

On Mon, Aug 29, 2011 at 5:17 PM, Stefan Bidi stefanb...@gmail.com wrote:
 I wasn't really following the previous string of e-mails (perhaps I should
 have).  Can you give me an overview of what the problem is and why
 initializing CF in [NSCFType+load] doesn't work?

http://gcc.gnu.org/onlinedocs/gcc/What-you-can-and-what-you-cannot-do-in-_002bload.html

e.g. NSCFType is not a subclass of NSCFString nor implemented in the
same file, thus the call to CFStringInitialize should be moved to
NSCFString +load.

that documentation doesn't seem to say you can't call objc_getClass(),
apparently you cannot... so the NSNull I added is broken also, its
just not crashing.
it's of the In particular, the following things, even if they can
work in a particular case, are not guaranteed: variety.

those were the 2 things that popped out at me looking through
CF*Initialize but i'm not all that familiar with the library.
Index: Source/objc_interface.h
===
--- Source/objc_interface.h	(revision 33795)
+++ Source/objc_interface.h	(working copy)
@@ -28,7 +28,7 @@
 #define __OBJC_INTERFACE_H__ 1
 
 #include CoreFoundation/CFRuntime.h
-#include GNUstepBase/preface.h
+#include objc/runtime.h
 
 
 
@@ -54,7 +54,7 @@
 CF_IS_OBJC (CFTypeID typeID, const void *obj)
 {
   return (typeID = __CFRuntimeClassTableCount
-  || object_getClass(obj) != __CFISAForTypeID (typeID));
+  || object_getClass((id)obj) != __CFISAForTypeID (typeID));
 }
 
 #define CF_OBJC_FUNCDISPATCH0(typeID, rettype, obj, sel) do { \
Index: Source/CFRuntime.m
===
--- Source/CFRuntime.m	(revision 33795)
+++ Source/CFRuntime.m	(working copy)
@@ -375,7 +375,6 @@
 extern void CFBundleInitialize (void);
 extern void CFNullInitialize (void);
 extern void CFNumberFormatterInitialize (void);
-extern void CFStringInitialize (void);
 extern void CFTimeZoneInitialize (void);
 extern void CFUUIDInitialize (void);
 
@@ -398,7 +397,6 @@
   CFBundleInitialize();
   CFNullInitialize ();
   CFNumberFormatterInitialize ();
-  CFStringInitialize ();
   CFTimeZoneInitialize ();
   CFUUIDInitialize ();
 }
Index: Source/CFUUID.c
===
--- Source/CFUUID.c	(revision 33795)
+++ Source/CFUUID.c	(working copy)
@@ -56,7 +56,7 @@
 	int fd;
 	unsigned int seed = 0;
 	size_t len = sizeof(seed);
-	BOOL hasSeed = NO;
+	Boolean hasSeed = false;
   
 	fd = open(/dev/random, O_RDONLY | O_NONBLOCK, 0);
 	if (fd = 0) 
@@ -64,12 +64,12 @@
   if (errno != EWOULDBLOCK)
 {
   if (read(fd, seed, len) == (ssize_t)len)
-hasSeed = YES;
+hasSeed = true;
 }
   close(fd);
 }
   
-	if (hasSeed == NO) 
+	if (hasSeed == false) 
 {
   struct timeval tv;
   unsigned long junk;
Index: Source/NSCFString.m
===
--- Source/NSCFString.m	(revision 33795)
+++ Source/NSCFString.m	(working copy)
@@ -35,7 +35,14 @@
 @interface NSCFString : NSMutableString
 @end
 
+extern void CFStringInitialize (void);
 @implementation NSCFString
+
++ (void) load
+{
+  CFStringInitialize();
+}
+
 - (id) initWithBytes: (const void*) bytes
   length: (NSUInteger) length
 encoding: (NSStringEncoding) encoding
Index: Source/CFBase.m
===
--- Source/CFBase.m	(revision 33795)
+++ Source/CFBase.m	(working copy)
@@ -250,7 +250,8 @@
 void CFNullInitialize (void)
 {
   _kCFNullTypeID = _CFRuntimeRegisterClass (CFNullClass);
-  ((CFRuntimeBase*)kCFNull)-_isa = [NSNull class];
+  /* don't use [NSNull class] before autorelease pool setup. */
+  ((CFRuntimeBase*)kCFNull)-_isa = objc_getClass(NSNull);
 }
 
 CFTypeID
Index: ChangeLog
===
--- ChangeLog	(revision 33795)
+++ ChangeLog	(working copy)
@@ -1,3 +1,13 @@
+2011-08-28  Matt Rice  ratm...@gmail.com
+
+	* Source/objc_interface.h: Remove reference to preface.h
+	add runtime.h.
+	(CF_IS_OBJC): Add cast to avoid warning.
+	* Source/CFRuntime.m: Remove call to CFStringInitialize.
+	* Source/CFString.m (+load): Move above call here. 
+	* Source/CFUUID.m: Replace BOOL/YES/NO with Boolean/true/false.
+	* Source/CFBase (CFNullInitialize): Avoid +initialize.
+
 2011-07-20 Stefan Bidigaray stefanb...@gmail.com
 
 	* Source/CFDate.c:
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: [patch] corebase/pyobjc

[Matt Rice]

On Mon, Aug 29, 2011 at 7:13 PM, Stefan Bidi stefanb...@gmail.com wrote:
 I still don't quite understand what is going on here.  CFStringInitialize()
 doesn't do anything accept call objc_getClass(NSCFString) (it's actually
 done by CFRuntimeBridgeClass).  According to the Apple docs this is safe
 because objc_getClass will call the class handler (not 100% what that really
 mean, but I thought it implied the class would get loaded if it belonged to
 the same framework) and try finding the class again afterward.

 Also, according to that doc, it isn't guaranteed that NSCFString is loaded
 before NSCFType, but how is this a problem?  CFString (and NSCFString)
 shouldn't be getting called during initialization anyway.

 I'm just trying to understand what your problem is and what is causing it.

I'm not too sure either, but If i had to venture a guess, i'd assume
the problem is that NSCFString's super-class is implemented in a
different framework, gnustep-base.

thus if corebase gets loaded first, NSCFType's super-class  NSObject's
+load is called, but doesn't initialize any of it's subclasses... then
it looks for NSCFString which isn't there yet

and if gnustep-base gets loaded first it goes through and initializes
all of its classes/subclasses, in that case NSCFString's super-class
exists at NSCFType call time and so it works.

or it could be that because *no* message is sent to the class from
+load to NSCFString it never gets installed until the end, because
IIRC it doesn't call __objc_install_class_links until that time...

It's really been years since I looked at the runtime so hopefully
someone else may be able to explain it.

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Problem with GDL2 palette

[Matt Rice]

On Sun, Aug 28, 2011 at 12:32 PM, Germán Arias ger...@xelalug.org wrote:
 Currently trying to add the GDL2 palette in Gorm, I get the error:

 Error
 (objc-load):/usr/GNUstep/Local/Library/ApplicationSupport/Palettes/GDL2.palette/./GDL2:
  undefined symbol: EOMPropertyPboardType
 2011-08-28 13:29:25.124 Gorm[7466] No classes in bundle

Yeah, that is because Dave Wetzel forked the top-level EOModeler/ dir
into Apps/EOModeler/ subdirectory
we now have 2 libraries with the same name, and different ABI's, awesome.

you'll need to A) cd EOModeler  make
and fiddle with the GNUmakefile for GDL2Palette to link against the right one...

then you'll have to unbreak DBModeler since EOModelerEditor doesn't
appear to work with it (it doesn't have the Pboard type, how can it?)
(GDL2Palette is useless on its own).

so you'll probably need to change the base classes of
EOEntity/Attribute/Relationship/Join/etc etc to EOCustomObjects,
otherwise things appear to work, but all data appears to be stale or
worse been a year since i've tried. that's something i recommended
to unbreak DBModeler but someone wanted to argue about it, so I forgot
about it...  If i work on it again i'll just post something on
gitorious.org,  I'll probably work on it again this week as I was
considering using EOInterface for something in the near future.

try the above things, and see how that works though.

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

[patch] Gorm, menu editor

[Matt Rice]

This fixes a NSApplication.m:3995:  NSLog(@Bogus attempt to set
main window);
from gorm when double clicking a pop-up button then trying to edit the
pop-up menu item by clicking on it,
not sure why it wants to be the main window, but it does..
it still seems to suffer from unmapping/remapping all windows causing a flicker,
but at least now it sometimes works.
Index: Palettes/0Menus/GormMenuEditor.m
===
--- Palettes/0Menus/GormMenuEditor.m	(revision 33793)
+++ Palettes/0Menus/GormMenuEditor.m	(working copy)
@@ -126,7 +126,7 @@
   NSPoint	loc = [theEvent locationInWindow];
   NSView	*hit = [super hitTest: loc];
   
-  [[self window] becomeMainWindow];
+  [[self window] makeMainWindow];
   [[self window] makeFirstResponder: self];
 
   if (hit == rep)
Index: ChangeLog
===
--- ChangeLog	(revision 33793)
+++ ChangeLog	(working copy)
@@ -1,3 +1,8 @@
+2011-08-28  Matt Rice  ratm...@gmail.com
+
+	* Palettes/0Menu/GormMenuEditor.m: Change becomeMainWindow call
+	to makeMainWindow.
+
 2011-05-17 20:43-EDT Gregory John Casamento greg.casame...@gmail.com
 
 	* GormCore/GormStandaloneViewEditor.h: 
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: NSMenuView patch

[Matt Rice]

On Fri, Mar 4, 2011 at 12:48 PM, Fred Kiefer fredkie...@gmx.de wrote:
 I just ran into a very annoying problem caused by our mouse capture in
 NSMenuView. When debugging an action method I put a breakpoint into that
 method and ended up with an unusable X windows desktop. The debugger
 would display its command prompt, but the mouse was still captured by
 the GNUstep menu window and I was unable to do anything.
 Looks like a duplicate call to capture actually has an effect only when
 out one is released the mouse will be usable again.
 This should also manifest itself in other cases, for example a modal
 window that gets started from a nested menu item. But I am unable to
 reproduce the issue there. I am not really sure what goes on here.

 The annoying bit is that I have to restart X each time I try this :-(

you might try looking up the xorg.conf setting, AllowDeactivateGrabs

it may help depending on if its supported in your X server (has been
varying over the years, haven't tried it recently)

otherwise starting up gdb from the console or ssh and attaching to the
process with --pid

I agree that its annoying, but really I don't think its anything
specific to Greg's patch, I'd run into the same with GNUstep years
ago.

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: NSMenuView patch

[Matt Rice]

On Fri, Mar 4, 2011 at 1:09 PM, Matt Rice ratm...@gmail.com wrote:
 On Fri, Mar 4, 2011 at 12:48 PM, Fred Kiefer fredkie...@gmx.de wrote:
 I just ran into a very annoying problem caused by our mouse capture in
 NSMenuView. When debugging an action method I put a breakpoint into that
 method and ended up with an unusable X windows desktop. The debugger
 would display its command prompt, but the mouse was still captured by
 the GNUstep menu window and I was unable to do anything.
 Looks like a duplicate call to capture actually has an effect only when
 out one is released the mouse will be usable again.
 This should also manifest itself in other cases, for example a modal
 window that gets started from a nested menu item. But I am unable to
 reproduce the issue there. I am not really sure what goes on here.

 The annoying bit is that I have to restart X each time I try this :-(

 you might try looking up the xorg.conf setting, AllowDeactivateGrabs

 it may help depending on if its supported in your X server (has been
 varying over the years, haven't tried it recently)

 otherwise starting up gdb from the console or ssh and attaching to the
 process with --pid

 I agree that its annoying, but really I don't think its anything
 specific to Greg's patch, I'd run into the same with GNUstep years
 ago.


I guess I should say, that ssh/trackball with button locking is really
the way to go for debugging these issues, as switching to the console,
and deactivating the grab are both going to modify the X event stream
which may or may not be a problem (though it usually isn't)

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: NSRunLoop Tidying

[Matt Rice]

On Fri, Oct 8, 2010 at 7:45 AM, Matt Rice ratm...@gmail.com wrote:
 On Fri, Oct 8, 2010 at 5:49 AM, Dr. H. Nikolaus Schaller
 h...@goldelico.com wrote:

 I don't think this is the case, if you no longer have to pass the
 nearest timer as a timeout for the polling mechanism,
 and the timerfd can be used to identify the timer

ahh, for some reason I ignored the pesky return value.

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: NSRunLoop Tidying

[Matt Rice]

On Fri, Oct 8, 2010 at 5:49 AM, Dr. H. Nikolaus Schaller
h...@goldelico.com wrote:
 Two aspects come to my mind that I think you have to consider:

 a) keep semantics of:

 -[NSRunLoop acceptInputForMode:beforeDate:]
 -[NSRunLoop limitDateForMode:]

 So I think you still need the sorted list of timers.

I don't think this is the case, if you no longer have to pass the
nearest timer as a timeout for the polling mechanism,
and the timerfd can be used to identify the timer

also, an implementation that would play nice with CFRunLoopObserver
for corebase?

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: [Gnustep-cvs] r31321 - in /tools/make/trunk: ChangeLog GNUstep.conf.in configure configure.ac

[Matt Rice]

On Fri, Sep 17, 2010 at 1:47 AM, Nicola Pero
nicola.p...@meta-innovation.com wrote:

 Well, if /usr/local/lib is not in ld.so.conf (it isn't by default on most
 Linux distributions), running ldconfig won't help.  So, we'd also have to
 hack
 /etc/ld.so.conf upon installation to add /usr/local/lib/ (or equivalent
 action on other unices) ... that is getting very system-specific
 and installation-unfriendly - we don't really want to do that.

agreed we don't want to do that,
but the gnu coding standards specify default install dirs here:

http://www.gnu.org/prep/standards/html_node/Directory-Variables.html#Directory-Variables

not to mention that this is a problem shared by ALL gnu software (on
systems that behave like you describe), and they all have a common
solution, where the gnustep solution is highly gnustep specific.

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: [Gnustep-cvs] r31321 - in /tools/make/trunk: ChangeLog GNUstep.conf.in configure configure.ac

[Matt Rice]

On Fri, Sep 17, 2010 at 2:22 AM, Richard Frith-Macdonald r...@gnu.org wrote:
 Remember, I'm not advocating switching to FHS as the default ... I'm 
 advocating switching to using the native layout as our default.  For systems 
 where FHS is not native, we would need to add another layout file.

this is something the gnu coding standards specifically say not to do,
same link as i sent to Nicola,

http://www.gnu.org/prep/standards/html_node/Directory-Variables.html#Directory-Variables

GNU packages should not try to guess which value should be appropriate
for these variables on the system they are being installed onto: use
the default settings specified here so that all GNU packages behave
identically, allowing the installer to achieve any desired layout.

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: [Gnustep-cvs] r31321 - in /tools/make/trunk: ChangeLog GNUstep.conf.in configure configure.ac

[Matt Rice]

On Fri, Sep 17, 2010 at 3:01 AM, Nicola Pero
nicola.p...@meta-innovation.com wrote:

 Remember, I'm not advocating switching to FHS as the default ... I'm 
 advocating switching to using
 the native layout as our default.  For systems where FHS is not native, we 
 would need to add another
 layout file.

 If this is for new users, having a common layout used almost everywhere may 
 help them as it's easier
 to find information.  So I'm not too keen to push this 'native' layout idea.

I would concurr,

the idea is that if (f(x) != f(x)) something is wrong, the system has
some form of outside influence, 2 users giving the same input come to
different results.

an associated problem is optional dependencies

the right questions to ask when diagnosing problems should be what
did you do? not:
what is x in magic place, I cannot tell you where to find it .
without information y, because a user generally can give you a vague
idea of what they did.

in otherwords, I think it is important for the build system to be a
pure function to the extent possible given the existence of system
differences.

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: [Gnustep-cvs] r31321 - in /tools/make/trunk: ChangeLog GNUstep.conf.in configure configure.ac

[Matt Rice]

On Fri, Sep 10, 2010 at 2:29 PM, Richard Frith-Macdonald r...@gnu.org wrote:

  IMO we need a system that just works.

agreed, the thing should work naively by default, and put the burden
of manual configuration/sourcing stuff onto those who want it that
way,

either what Richard did, or by moving 'Tools' out to /usr/bin so
gnustep-config could be found and linking with rpath (this 2nd
solution is unlikely to work for distributions which disallow rpath,
leads to unrelocatable binaries, and i hesitate to recommend rpath as
a solution to anything).

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Is there a 2D plotting (charting) library running under GNUStep?

[Matt Rice]

On Sun, Sep 5, 2010 at 1:28 PM, Marek Peca ma...@duch.cz wrote:
 Hello,

 I would like to integrate simple 2D line plots into my application. I did it
 few years ago under Athena, so I managed some basic tasks like axis
 autoscaling etc. However, I have heard a lot about quality plotting packages
 under early NeXTStep, so if there is anything ready to use, I would better
 use the much more advanced code by other people, than to write my silly
 hacks (although at least the bare drawing is easy with NSBezierPath, there
 is lot of work with labels, tics etc.).

 I have found some OS X and Cocoa user discussions around this topic,
 including references to nxyplot and XYPlotView, and HippoDraw and SciPlot as
 well.

 /* some refs:
 http://www.omnigroup.com/mailman/archive/macosx-dev/2002-May.txt
  | grep -i xyplot
 http://lists.apple.com/archives/cocoa-dev/2003/Mar/msg01675.html
 ftp://ftp.next.peak.org/pub/next-ftp/next/sourcelibrary/palettes/XYPlotPalette.0926.NIHS.bs.README
 */

 Are there GNUStep compatible ports of any of these old gems?

 It seems that HippoDraw has converted to Qt. I know about Gnuplot, but I
 think, that it is almost impossible to be used as a library. Any other
 working classes?


there is also aquaterm, I posted patches for a port of it many years
ago on the aquaterm list, but don't think i recieved any feedback, it
is no doubt out of date.

IIRC it can be used as a library + app combo, so the library connects
via DO to the aquaterm application, not sure if it can be used solely
a library for e.g. generating graphics.

http://aquaterm.sourceforge.net/

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: NSTabView problem

[Matt Rice]

On Fri, Aug 13, 2010 at 1:32 AM, Fred Kiefer fredkie...@gmx.de wrote:
 Am 12.08.2010 01:27, schrieb Matt Rice:
 On Wed, Aug 11, 2010 at 10:19 AM, Fred Kiefer fredkie...@gmx.de wrote:
 The libffi problem will result in no images being displayed. As this
 isn't the case for you, this looks like some different issue.

 I can't remember if it was all images, or just named images that had
 the libffi problem?


 It's named images that wont work with a broken libffi.


looking at this,
http://coyote.octets.fr/simpleagenda/browser/trunk/CalendarView.m
and the _1left, _1right etc, i'm guessing those are the images we're
seeing in the screenshot
and they are loaded not by name but by file, so i'm guessing that
libffi being the problem is still in play.

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: NSTabView problem

[Matt Rice]

On Wed, Aug 11, 2010 at 10:19 AM, Fred Kiefer fredkie...@gmx.de wrote:
 The libffi problem will result in no images being displayed. As this
 isn't the case for you, this looks like some different issue.

I can't remember if it was all images, or just named images that had
the libffi problem?

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: how to port gorm files to renaissance?

[Matt Rice]

On Mon, Apr 26, 2010 at 7:12 PM, Gregory Casamento
greg.casame...@gmail.com wrote:
 It would be easier to save them as nibs.  To convert them to
 Renaissance the only way is to do it by hand.

 On Monday, April 26, 2010, David Wetzel d...@turbocat.de wrote:
 Hi folks,

 I would like to be able to use the inspector on GDL's DBModeler on OS X.
 But those inspector interfaces are made with gorm.
 How can I convert them to use renaissance without having gorm?


yeah, I agree... originally i had intended to move the whole shebang
to renaissance and the inspectors turned out to be fairly difficult.

mainly because they are in a constrained space, and getting
the autolayout to work in that constrained space and look good
proved very difficult, you'd pretty much need to forgo the autolayout
mechanisms in renaissance and place everything with absolute
positioning

in addition to that there is alot of stuff like

a | x
b | y
c | z
--
in the inspectors,
with a | x aligned horizontally, but
abc aligned vertically,  and the box based autolayout mechanisms
made it easy to get abc aligned vertically or ab by cz aligned
horizontally, but getting them both to align proved a challenge.

i'll try and convert them to nib and send them to you tonight.


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Next GNUstep release?

[Matt Rice]

On Sun, Mar 28, 2010 at 11:37 PM, Gregory Casamento
greg.casame...@gmail.com wrote:
 Hey guys...  Matt and I just talked via IM and he reminded me of a
 really important point.

 The functionality using proxies works fine on 32bit machines, but is
 broken on 64 bit machines due to the fact that this bug:

 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40700


named colors have this exact same issue and they were (haven't looked
in a while) able to change without resorting to using an NSProxy for
the color,

the idea was that NSView observes the change, sets itself as needing
redisplay, and views which cache colors are responsible to recache it,
or they will keep displaying the old color, or crash if they cached
and failed to retain it, this in my opinion works adequately.


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Next GNUstep release?

[Matt Rice]

On Sat, Mar 27, 2010 at 3:48 PM, Adam Fedor fe...@qwestoffice.net wrote:

 On Mar 26, 2010, at 1:55 PM, Fred Kiefer wrote:

 Adam, could you once more take up the task of releasing GNUstep? We
 should give it another week or two so that people can complain about
 existing bugs that need to be fixed before the release.

 I'll help make a release whenever it's ready.


So, i tried it out since theres a release on its way, I noticed 2 things,

named images (aka system images) do not work, with any backend i've tried,
so radio buttons, check boxes, tabs in tabviews, and knob things in
outline views are all invisible.

the attached patch is an ugly hack that should give you guys an idea
of the problem.
something is going in the image proxy code, I really don't understand
what is so bad about having to restart an app to change the themes.

the 'Images' button in Gorm in the main window shows no images,
this last one is because gorm is using NSSystemDomainMask but they're
being installed into NSLocalDomain GormCore/GormFunctions.m
systemImagesList() and systemSoundsList() should probably now be using
NSAllDomainsMask.


foo.diff
Description: Binary data
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Gorm brokeness

[Matt Rice]

On Mon, Mar 8, 2010 at 1:30 AM, Richard Frith-Macdonald
rich...@tiptree.demon.co.uk wrote:

 On 8 Mar 2010, at 06:22, Richard Frith-Macdonald wrote:


 On 7 Mar 2010, at 19:10, Fred Kiefer wrote:

 Just to keep you informed on my current finding. I could follow a mouse
 down event that should start a drag into the method [XGDragView
 dragImage:at:offset:event:pasteboard:source:slideBack:] there the call
 to mimeTypeForPasteboardType() seems to fail, when doing manual calls in
 gdb I get

 (gdb) po pboard
 NSPasteboard: 0x11b68e0
 (gdb) p [pboard types]
 $14 = (class NSArray *) 0x109a610
 (gdb) po [pboard types]
 NSDistantObject fee2c0
 (gdb) p [[pboard types] count]
 $15 = (void *(*)()) 0x7fffef701000
 (gdb) p (int)[[pboard types] count]
 $16 = -277884928
 (gdb) p (long)[[pboard types] count]
 $17 = 140737210454016

 Now this may not the the root of the problem, but it looks strange to
 me. But why wont the function mimeTypeForPasteboardType return?
 After adding a breakpoint in [NSException raise] I get:

 (gdb) bt
 #0  -[NSException raise] (self=0x1056940, _cmd=0x76c03ab0) at
 NSException.m:899
 #1  0x76818300 in -[NSConnection(GNUstepExtensions)
 forwardInvocation:forProxy:] (self=0xfba420,
   _cmd=0x76c105c0, inv=0x1062840, object=0x11a81a0) at
 NSConnection.m:2090
 #2  0x76928507 in GSFFIInvocationCallback (cif=value optimized
 out, retp=0x7fffc670,
   args=value optimized out, user=value optimized out) at
 GSFFIInvocation.m:636
 #3  0x747d9729 in ffi_closure_unix64_inner (closure=value
 optimized out,
   rvalue=value optimized out, reg_args=0x75d04d3a,
 argp=0x7fffc690 @#�)
   at src/x86/ffi64.c:620
 #4  0x747da0b0 in ffi_closure_unix64 () at src/x86/unix64.S:228
 #5  0x731f799a in mimeTypeForPasteboardType (types=value
 optimized out,
   zone=value optimized out, xDisplay=value optimized out) at
 XGDragView.m:140
 #6  -[XGDragView dragImage:at:offset:event:pasteboard:source:slideBack:]
 (types=value optimized out,
   zone=value optimized out, xDisplay=value optimized out) at
 XGDragView.m:217
 #7  0x77b3895d in -[GormPaletteView mouseDown:] (self=0xcdd460,
 _cmd=value optimized out,
   theEvent=0xf8cd00) at GormPalettesManager.m:236
 #8  0x76ff7393 in -[NSWindow sendEvent:] (self=0xc32340,
 _cmd=value optimized out,
   theEvent=0xf8cd00) at NSWindow.m:3666
 #9  0x76e94af4 in -[NSApplication run] (self=value optimized
 out, _cmd=value optimized out)
   at NSApplication.m:1530
 #10 0x76e7612e in NSApplicationMain (argc=value optimized out,
 argv=value optimized out)
   at Functions.m:74
 #11 0x75ca5a7d in __libc_start_main () from /lib64/libc.so.6
 #12 0x00401ac9 in _start () at ../sysdeps/x86_64/elf/start.S:113

 (gdb) po self
 NSException: 0x1056940 NAME:NSInvalidArgumentException REASON:subclass
 GSMutableArray(instance) should override count


 Looks like this method go lost in recent rewrites of base :-)

 Absolutely not.
 It's 'inherited' from GSArray using behavors, so should not be implemented 
 in GSMutableArray.
 Also, many of the regression tests and lots of other code would clearly have 
 failed horribly if mutable arrays didn't work.
 So how can you get this exception?  Presumably some runtime issue.  I 
 rewrote the behavior code to use the new runtime API rather than the old 
 one, and while it's clearly working fine most of the time, perhaps there's 
 something finding a bug in this case?

 I will fix this and also change all the parameters in GSArray.m to
 NSUInteger that are now changed in the super class NSArray.

 Now this looks also like a possible cause of the problem (especially if the 
 people experiencing this problem are using 64bit systems and it's not 
 showing up on any 32bit systems).

 I'll remove the -count method again, and we can see whether the change to 
 using NSUInteger fixed the issue.

 I''ll also look see if I can spot any possible problem in the mechanism for 
 inheriting -count.

 None spotted so far.  I have improved the debug though...

 If you set the GNUSTEP_BEHAVIOR_DEBUG environment variable to YES,  you will 
 get all the inherited behaviors logged to stderr and can see if there is 
 anything going wrong there.  It will report each method added or replaced in 
 the class (as well as methods skipped because the class already has an 
 implementation).

  So if the NSUinteger changes did not fix things, and there is an issue with 
 'inheriting' the -count method, this should give us a clue about where to 
 look.


It doesn't seem related, but i've also been seeing some runtime weirdness
where objc_lookup_class(NSString) returns a bad class variable,
i've tracked it somewhat setting watchpoints on  class_table_array[52]
and seen the 'correct' class being set as
class_table_array[52]-pointer (where 52 is the hash value for
NSString)

but haven't tracked down where -pointer goes invalid, it seems to
just have a slight difference where the good one is 

Re: includes/imports in gui.

[Matt Rice]

On Fri, Feb 19, 2010 at 1:23 AM, Fred Kiefer fredkie...@gmx.de wrote:

 I would like to differ. For me the best way seems to be to have the
 extensions not automatically included. That will break existing
 projects. (In most cases it will just cause warnings from the compiler
 about methods not being defined) But it will also make clear that this
 project will need to be adapted to be usable on OSX. For gui itself I am
 willing to make the changes, in many cases just remove the use of the
 extensions, in others just an additional include.

completely agree with this part.
additions should be additions, the requirements to use them should be
the same no matter what platform you're on OSX or GNUstep.
it is a 180 from traditional GNUstep behavior but I would consider
this change to be fixing a past mistake.


 This is just what I think, it will be more important to get feedback
 from the maintainers of GNUstep applications. If they think the clear
 way is to much hassle for them, we should have the additions
 automatically included.

don't agree so much with this :)


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Question about GNUstep DL2

[Matt Rice]

On Fri, Jan 8, 2010 at 5:07 AM, Yavor Doganov ya...@gnu.org wrote:
 gnustep-dl2 [1]
  DBModeler
  GDL2 palette
  eoutil, gdlgsdoc
  EOModeler (as private library)
 Recommends: libeointerface-dev (which will pull in libeoaccess-dev)

Sorry It just hit me that  both DBModeler and GDL2 palette use the
EOModeler library which might pose a problem for making EOModeler
'private' (not sure how you go about achieving this private library
really.)

the GDL2 Palette dependency on EOModeler would be trivial to remove,
the only thing GDL2Palette should use in EOModeler is the
EOMPropertyPboardType, which is just a variable containing a string,
which could be hard coded in a debian local patch or something, sorry
I didn't think about this yesterday.


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Question about GNUstep DL2

[Matt Rice]

On Mon, Jan 4, 2010 at 5:31 AM, Yavor Doganov ya...@gnu.org wrote:
 Matt Rice wrote:
 Yavor mentions that (although they're intended to be public
 libraries, nothing in GNUstep uses them)

 Oh, that was misleading.  What I meant is that no package in Debian
 currently uses gnustep-dl2 (its libraries or whatever).



 but DBModeler isn't really a standalone application, the model files
 it generates are intended to be used by the libraries,

 ...which in turn are used by applications, right?  That's what I was
 saying.  But we'll ship all libraries anyway, the question was how.

 the EOControl/EOAccess split from EOInterface would just be nice in
 the case where someone wants to install something like a GSWeb
 application onto a web server, where EOInterface in X and
 gnustep-gui and a lot of unnecessary stuff

 I agree it would be nice.

 I'm not sure if it would be against debian policy to ship the Gorm
 bundle with DBModeler.app

 Yes, that's perfectly fine.

 gnustep-dl2-libs/gnustep-dl2-libs-dev:
 EOControl - gnustep-base
 EOAccess - EOControl

 This won't work, the package will have the same problem as the
 gnustep-dl2 package now.  Let me explain simply the policy.  Every
 shared library (in /lib and /usr/lib) should be packaged as libfooN
 and libfoo-dev (in rare cases libfoo2-dev).  This is to allow packages
 that use the library to depend on libfoo-dev and to automatically
 generate the libfooN dependency of the binary package via the shlibs
 mechanism.  Embeding the soname N in the package name is essential
 to handle library transitions.  Packages without reverse dependencies
 (e.g. all of gnustep-dl2's libraries) are considered harmful, as the
 main reason for packaging a library is to handle properly dependencies
 for stuff (in the distro) that uses it.  They're basically clutter --
 it is considered that if a library is interesting, useful and mature,
 people will develop apps that make use of it.  More binary packages
 also adds extra load on the Debian infrastructure.

 (For example: libCynthiune is intended by its author to be a public
 library, allowing people to develop third-party bundles for Cynthiune.
 But since no such bundles exist, we ship it under
 /usr/lib/cynthiune.app within a single cynthiune.app package.  If
 someone writes a bundle or two worth packaging some day, we'll split
 the library in libcynthiune0/libcynthiune-dev.  Now it would be a
 waste.)

 Anyway, I explicitly assume that we're going to ship all EO* libraries
 as public libraries, to help users who might eventually develop useful
 free software (or easily build manually what is available but not yet
 packaged).  GDL2 is more than a music player, after all :-)



 So, having said that the binary package name must match the soname,
 the above pair should be libeoaccess0/libeoaccess-dev, but that would
 be again a violation because it includes EOControl as well.  This is
 allowed in certain situations (for example, libglib2.0-0 contains 5
 tightly related libraries) when the libraries are meant to evolve
 together.  Is that the case here?

I see, splitting these up should be fine, IMO, (now that gdl2.make no
longer automatically links to both EOAccess/EOControl)
the main reason i lumped them together is that it is very rarely that
anything will depend on EOControl without EOAccess, and EOAccess
shouldn't bring in any additional dependencies.


 gnustep-dl2-interface/gnustep-dl2-interface-dev:
 EOInterface - EOAccess + gnustep-gui

 Likewise, this should be libeointerface0/libeointerface-dev.  But you
 didn't mention EOModeler.  Is its place here, too?  If so, what I said
 above applies here as well.

Ahh, yeah I forgot about that library, no EOModeler can go in its own
libeomodeler

 gnustep-dl2-devtools:
 GDL2Palette - EOInterface + Gorm libs
 DBModeler - EOInterface + renaissance

 Or gnustep-dl2-tools, gnustep-dl2-bin, or simply gnustep-dl2.  Perhaps
 -devtools is most descriptive.  I guess this is the place to include
 eoutil, gdlgsdoc and gdl2.make, right?

OK with me, I'm not exactly sure what to do with gdl2.make, but I'm
kinda guessing that it should go with the headers for
EOControl/EOAccess, but not knowing how/if applications are using it
since the changes described above, so i can't exactly give you a good
answer on that.  Though it does provide command line preprocessor
definitions which presumably some application could be using when
compiling software ported to gdl2, from EOF.

 gnustep-dl2-postgres-adaptor:
 Postgres adaptor - EOAccess + Postgres libs (build dep on gui for the
 login panel [1])

 I sense some confusion here.  There is going to be one gnustep-dl2
 source package, which already build-depends on libgnustep-gui-dev.
 (Build-Depends/Depends for source/binary packages in Debian are what
 Build-Requires/Requires are in the rpm world for SRPM/RPM.)

 Here we'll hit the same problem, as there are libPostgreSQLEOAdaptor
 and libSQLite3EOAdaptor in /usr/lib.  Is something intendend to link

Re: Question about GNUstep DL2

[Matt Rice]

On Thu, Jan 7, 2010 at 1:12 PM, Yavor Doganov ya...@gnu.org wrote:
 Matt Rice wrote:
  Likewise, this should be libeointerface0/libeointerface-dev.  But
  you didn't mention EOModeler.  Is its place here, too?

 Ahh, yeah I forgot about that library, no EOModeler can go in its own
 libeomodeler

 But the goal is to decrease the number of the binary packages as much
 as possible...
 If EOControl/EOAccess are together, this makes

 6 library packages + 2 adaptors + -devtools = 9 packages :-(

forgive me I am confused I was under the assumption that debian policy
forced us to split EOAccess/EOControl.

 If EOModeler is acceptable (from upstream's POV) to be shipped
 together with EOInterface, the number is 7 which is more palatable.

sure, but it makes more sense to ship with DBModeler/devtools IMO,

the EOModeler library is to DBModeler what libcynthiune in your
previous example is to cynthiune.
used to write bundles for extending DBModeler, similarly there no real
bundles actively in use that use it, but it should straight forward to
port bundles from the original EOModeler, of which there are a few
available, but I haven't bothered to port them.

It could be shipped with EOInterface, but the connection between the 2
is more tenuous in that the only thing they have in common is that
they use gui, and DBModeler has dependencies on both, while
EOInterface is useful without DBModeler installed (in the context of
an application depending on EOInterface) the EOModeler library is not.
 DBModeler is in fact a bunch of EOModeler bundles which instead of
being dynamically loaded, are linked directly into the application + a
main loop.

I'm much less averse to debian installing EOInterface private with
devtools than EOAccess/EOControl, if you feel the need to bundle that
with devtools privately go ahead, the package while not complete would
still be useful to the largest portion of the target audience, then
EOModeler/EOInterface could be split out if they are needed by
bundles/applications.

What about OGO/SOGo?  IIRC they maintained their own fork of
gnustep-dl2, or maybe it was not a fork but a different
implementation?  (Not that we have the manpower to maintain a big
thing like SOGo, but still...)

OGO uses a fork of parts of gdl1, so I'd assume that SOGO does too,


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Question about GNUstep DL2

[Matt Rice]

On Mon, Jan 4, 2010 at 1:37 AM, Federico Gimenez Nieto fgime...@coit.es wrote:
 El 03/01/2010 21:26, Matt Rice escribió:
 [.]
 I'm not sure if it would be against debian policy to ship the Gorm
 bundle with DBModeler.app that is another option if possible since the
 gorm bundle is like a plugin for Gorm which DBModeler communicates
 with, its not entirely necessary, but is required to use DBModeler
 with gorm, and only DBModeler uses it (communicating via the
 pasteboard).


 AFAIK, since gorm.app is already part of debian, that package should be
 used instead of including convenience copies of code, see [1] for
 details. On fact, the current gnustep-dl2 package depends on gorm.app
 for its build and installation. But right now the public libraries of
 gorm aren't packaged as separated shared libraries, Yavor also suggested
 this as a prerrequisite, [2]


Ahh, sorry I meant the 'package GDL2Palette bundle with DBModeler',
adding a dependency on the existing Gorm.app package to it,
it is more of a private shared library/plugin sort of thing, not
intended to be linked to anything,
so if i understand correctly it would be alright to ship that with DBModeler?


 [.]
 I don't really know anything about debian packaging so i'm not sure if
 you could do some meta package, where Postgres adaptor/SQLite3 adaptor
 provide a 'EOAdaptor' and these are recommended by EOAccess, but not
 mutually exclusive so either/both could be installed



 AFAIK that could be done with a virtual package, [3]. It seems to me
 that the same functionality could be achieved with the separate
 gnustep-dl2-postgres-adaptor and gnustep-dl2-sqlite3-adaptor packages,
 including an OR'ed dependency on the related packages. What would be the
 advantages of having the EOAdaptor umbrella?


I think that the advantages are just mostly future-proofing, there
exist are not copyright owned by the FSF, and so they are not
distributed with GDL2, which have been ported by various people,
typically from EOF adaptors...

also with databases like oracle maintaining their own apt repository
there is potential for adaptors with non-free dependencies and so on.
I think either the virtual package or the OR'd dependencies will work
for now though.

since the 3rd party ported adaptor(s) generally lack any formal
'project' and formal release process, they're probably not eligible
for inclusion into debian, and no adaptors exist with dependencies on
non-free actually exist (to my knowledge), I think it is up to you
whether you would want to future proof for that sort of thing, or
cross that bridge if/when it is ever needed to be crossed


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Question about GNUstep DL2

[Matt Rice]

2010/1/3 Federico Giménez Nieto fgime...@coit.es:
 Hi all,

 I'm in the process to adopt gnustep-dl2 debian package, [1]. You can
 check the progress so far at [2]. In order to comply with Debian
 Policy, Yavor Doganov (Cc'ed) suggested that the libraries in the
 package (libEO*) should be packaged separately from dbmodeler.app
 ([3], [4]). As Yavor pointed out, there are at least three
 alternatives for packaging the libraries:

 - As private libraries.
 - Bundled into libgnustep-dl2-0 and libgnustep-dl2-dev.
 - Separately as libraries on their own.

 What do you think would be the best option to do so?

In my opinion the best option would be to do the libraries separately
on their own,
or possibly just split the EOControl/EOAccess into one package, and
EOInterface/GDL2Palette into another package
with a 3rd package for DBModeler, or package DBModeler/GDL2Palette together

Yavor mentions that (although they're intended to be public
libraries, nothing in
GNUstep uses them)

but DBModeler isn't really a standalone application, the model files
it generates are intended to be used by the libraries,
the EOControl/EOAccess split from EOInterface would just be nice in
the case where someone wants to install something like a GSWeb
application onto a web server, where EOInterface in X and gnustep-gui
and a lot of unnecessary stuff

I'm not sure if it would be against debian policy to ship the Gorm
bundle with DBModeler.app that is another option if possible since the
gorm bundle is like a plugin for Gorm which DBModeler communicates
with, its not entirely necessary, but is required to use DBModeler
with gorm, and only DBModeler uses it (communicating via the
pasteboard).

lastly there are the adaptors which pull in the various database
dependencies (Postgres/SQLite3 at the moment) those could be bundled
separately... anyhow here is how i'd consider with silly made up
package names followed by the basic components and their dependencies

gnustep-dl2-libs/gnustep-dl2-libs-dev:
EOControl - gnustep-base
EOAccess - EOControl

gnustep-dl2-interface/gnustep-dl2-interface-dev:
EOInterface - EOAccess + gnustep-gui

gnustep-dl2-devtools:
GDL2Palette - EOInterface + Gorm libs
DBModeler - EOInterface + renaissance

gnustep-dl2-postgres-adaptor:
Postgres adaptor - EOAccess + Postgres libs (build dep on gui for the
login panel [1])

gnustep-dl2-sqlite3-adaptor:
SQLite adaptor - EOAccess + SQLite3 libs (build dep on gui for the
login panel [1])

(and possibly a convenience package to install the whole shebang)

then in the future things like GSWeb could just go
GSWeb - EOAccess + apache
and some EOInterface using application wouldn't necessarily need Gorm
and DBModeler. so it could just depend on EOInterface.

so the dependency tree at least has 3 ways of growth
server based/headless applications, gui applications, and developer tools

I don't really know anything about debian packaging so i'm not sure if
you could do some meta package, where Postgres adaptor/SQLite3 adaptor
provide a 'EOAdaptor' and these are recommended by EOAccess, but not
mutually exclusive so either/both could be installed

quite a few packages, but that sort of package layout would mimic the
various configurations available to those who build the package from
source.

[1] most of the components of GDL2 don't change based on how it is
configured, they just enable and disable whole components
the only exception to this (that I can think of at the moment) is the
login panel code contained in the EOAdaptors, which enables a separate
shared library containing gui code, gui apps can call login panel
associated methods, which loads the bundle if gui is found at runtime,
these may need to be split out into their own e.g.
gnustep-dl2-postgresql-loginpanel package to avoid bringing in gui
just for the login panel which should be optional, to allow debian to
maintain the dependency on gui.  Currently there is no way to build
the login panel, while installing it separately, ripping out the
LoginPanel.bundle directory from the adaptor's .framework/Resources
into its own package would work, but it isn't exactly elegant.

anyhow, i believe you could possibly get away with a single top-level
configure/make
then make -C Component DESTDIR=/path/to/package/dir install
hopefully this helps, let us know if there is anything we can do on
the GDL2 side to make your job as packager any easier.

Thanks.


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: [Fwd: Re: GNUstep and Linux Fund]

[Matt Rice]

On Thu, Nov 12, 2009 at 8:55 AM, David Chisnall thera...@sucs.org wrote:
  Having the main menu a single click away without having to move the mouse is 
 a good design from the point of
 view of usability.  A menu that appears where the mouse is beats both a menu
 attached to the window and a menu attached to the screen in Fitts' Law
 terms.

hmm, I'm not sure I entirely agree with this in regard to the GNUstep
implementation.

on OPENSTEP the menu would appear even if you clicked outside of the
window there fullfilling what you say above, but
under GNUstep the menu only pops up when right clicking inside of the
window, meaning that it only works in Fitts' Law terms
if the cursor is over a window.

I can't remember the behavior of OPENSTEP when right clicking over a
window for an app which is not the current active application, I would
assume that it would make sense to activate the other application and
display its menuForEvent: ?

in the window manager i was writing, it would forward right mouse
click events from the root window to the to the currently focused
window, which with some modification to GNUstep i could get it to pop
up the main menu, but I could never really get the mouse tracking to
work, and don't really remember the details.

Anyhow OPENSTEP had much more girth to the amount of space on screen
where you could get the menu immediately under the mouse.

I could dig up the code if anyone is interested


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Changes I've been thinking of...

[Matt Rice]

On Fri, Oct 9, 2009 at 1:37 AM, Nicola Pero
nicola.p...@meta-innovation.com wrote:

 Additionally I really dislike the coding style, not because it's not
 mine, but because it fails to make the code more readable. On the
 other hand, there was code by Fred which looked really ok, so maybe
 it's just about using the coding style in a sane way All I
 wanted to say is, that it's not that easy to start hacking inside
 the GNUstep core libraries.

 Completely agree.  Good coding conventions are picked because they
 make things that are wrong look wrong or generate compiler errors /
 warnings.  The GNU coding conventions were picked by selecting at
 random various bits from all existing coding conventions in the hope
 that that would make everyone happy.  They are a horrible mash of
 things.  The indenting style is horrible, for example, and only works
 if you have your editor set up in exactly the same way as RMS;
 mixing  tabs and spaces for indenting is one of the most stupid ideas
 I've  ever seen.  The convention of putting a space after function
 names and  before the open bracket makes code harder to read because
 it makes it  difficult to tell without reading the context that
 something is an  argument list rather than a subexpression.  In fact,
 almost everything  about the GNU coding conventions looks painfully
 stupid to anyone with  a basic understanding of how the human visual
 system works, but as an  official GNU project we are stuck with it.

 I didn't know you have to stick to the GNU coding guidelines if you are
 an official GNU project. Now I understand all the people complaining
 about gcc being unreadable...

 Just to clarify for the non-developers, GCC being unreadable is a completely
 different problem,
 not particularly due to the coding style. ;-)

 Having a standard coding style for the whole GNUstep project is really
 important as it makes
 it easier to copy/move code from one part of the project to the other.
  Using a standard coding
 style that is documented and used by many other projects is also good as
 contributors will
 be immediately familiar with it.

 The GNU coding standards are used by a large number of projects with a lot
 of contributors
 and popularity so can't really be blamed if GNUstep is less popular than,
 say, GIMP (which also
 happens to follow the GNU coding standards) or any of the other million
 projects that use the
 GNU coding standards or some variants of them.

 While I sympathize with David who prefers (or is used) to some other coding
 style,
 the GNUstep project needs a consistent coding style and the GNU coding
 standard
 are as good a choice as any.  Since GNUstep is a GNU project, it's a natural
 choice.

 By the way the GNU coding standards are not bad, in fact I personally like
 them (mostly because
 my eyesight is really bad and whitespace is much more effective at
 separating tokens than
 brackets or commas).  There are some details I'd change, but they certainly
 are not an unusual
 or weird choice for a large free software project.

To me it is about separating groups of tokens, e.g. if you are going
to separate like this

[thing foo: arg1 bar: arg2];

and insist on including that space between the 'foo:arg1' group,
the whole message send looks androgynous with parts of the selectors
mixed in with their arguments...

compared with
[thing foo:arg1 bar:arg2];

it is very easy for me to pick out which args go with which parts of
the selector, and
which message is being sent...

 If it's a burning issue for many developers, I guess changing the coding
 style to something else
 could be discussed.  There would be *lots* of reformatting to do if we ever
 reach an agreement
 on some other coding style. ;-)

consider me on fire then, the reformatting is no issue for me, since I
generally reformat the code i'm looking at anyways
then I fix whatever i'm doing, and to send a patch to GNUstep do a
clean checkout then uglify my code to fit the GNUstep style...

I did a quick google code search on some random method
and counted up how the arguments were formatted

92: with space between colon and argument
265: without space between colon and argument

not really a scientific study of developer preference... (considering
some of my code showed up in the with-space list which i can't stand),
there is also bound to be duplicates of code between different
versions of the same software...

so if you're going to insist on one true whitespace,
don't insist on one only a minority of developers use,
or people are bound to complain, and call the gnustep code ugly.

so just in case i haven't made my stance on the subject clear, I'd
have to Ditto what icicle and David are saying.


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Changes I've been thinking of...

[Matt Rice]

On Fri, Oct 9, 2009 at 12:51 PM, Quentin Mathé qma...@gmail.com wrote:
 Le 9 oct. 2009 à 20:48, Matt Rice a écrit :

 On Fri, Oct 9, 2009 at 1:37 AM, Nicola Pero
 nicola.p...@meta-innovation.com wrote:

 By the way the GNU coding standards are not bad, in fact I personally
 like
 them (mostly because
 my eyesight is really bad and whitespace is much more effective at
 separating tokens than
 brackets or commas).  There are some details I'd change, but they
 certainly
 are not an unusual
 or weird choice for a large free software project.

 To me it is about separating groups of tokens, e.g. if you are going
 to separate like this

 [thing foo: arg1 bar: arg2];

 and insist on including that space between the 'foo:arg1' group,
 the whole message send looks androgynous with parts of the selectors
 mixed in with their arguments...

 compared with
 [thing foo:arg1 bar:arg2];

 it is very easy for me to pick out which args go with which parts of
 the selector, and
 which message is being sent...

 Well it's possible to argue in the opposite way :-)
 The first version is more readable than the second, because it's very easy
 to spot each 'colon + white space' combination.
 Then you know the left part is a method keyword and the right part is the
 argument.
 In the second case, 'colons' without white space seems slower to find
 because they are lost in the middle of other characters.

 The first version is also closer to the spirit of Smalltalk, in the sense
 the punctuation related spacing is similar to a real sentence.
 imo Smalltalk code with this spacing style is clearer than Smalltalk code
 without a space between each method keyword and argument pair.
 This point is less important in Objective-C given the whole language syntax
 is far less clean (C syntax + brackets everywhere). But it still matters a
 bit I think. I agree I'm getting really subjective here :-)


of course... each language is different in scheme
(+(+ 1 2) 3) looks horrible compared to
(+ (+ 1 2) 3)

I'm assuming that RMS being a lisp programmer, this must be the reason
why the GNU coding standards do it this way, but that doesn't make it
right for objective-c.


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Changes I've been thinking of...

[Matt Rice]

On Thu, Oct 8, 2009 at 5:30 AM, Richard Frith-Macdonald
rich...@tiptree.demon.co.uk wrote:

 OK ... we just have different perceptions here then.  In those circumstances
 I expect a package to be *available* to all users, but NOT to be
 automatically forced on them.
 Certainly *I* don't want to have something like that imposed on *ME* just
 because someone else installs a package globally.

there is no enforcing here,

people could easily set

defaults write NSGlobalDomain GSAppKitUserBundles '()'

to get no theme bundles, I do this e.g. for using themes in every
application except Gorm
It just pushes the burden of setting defaults onto those that don't
want to follow the global installation
instead of those that do, I am completely fine with installing
defaults system wide
(as long as the system domain doesn't override the global domain)


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Changes I've been thinking of...

[Matt Rice]

On Wed, Oct 7, 2009 at 2:59 PM, Philippe Roussel p.o.rous...@free.fr wrote:
 Hi

 What I'm trying to say is that I think we should try to centralize
 things (one repository for all !) and work on a set of defined
 applications instead of collecting random stuff.

Yuck.

first of all, this is impossible, because not everything out there is
copyright assigned.

IMO the way to go is decentralized,

that doesn't mean we can't have a central repository to collect all
the various decentralized projects in one easy to grab location.

doing this would also allow for the various forks out there to usurp
one another, if one repository dies, and someone picks it up, just
update the location in the 'central collection' to point to a new
repository maintained by whomever.

then the GNU FSF-copyright assigned collection only references GNU FSF
copyright assigned code, and someone else (e.g. the gap project) could
create a project which references the copyright assigned code, + the
other non assigned projects

ideally you'd be able to build all the sub-projects i one go,
something that we don't get in our existing build system.


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Error compiling libobjc2 - unwind.h not found

[Matt Rice]

On Sun, Oct 4, 2009 at 7:30 AM, David Chisnall thera...@sucs.org wrote:
 Hi Chris,

 It's a private GCC header which, unfortunately, varies a little bit between
 platforms.  I'm a bit surprised it isn't found for you; it has been on all
 of the platforms that I've tried so far, but in some uleb128 is defined and
 in others it isn't.  I plan on removing this dependency soon, because the
 unwind headers just contain copies of the functions from the ABI
 specification (which doesn't seem to stop the FSF from slapping a GPL header
 on them).

Yeah, i thought it referred to that unwind.h,
the use of unwind.h made me wonder though, why not unwind.h?

http://packages.debian.org/lenny/gcc-3.4
http://packages.debian.org/lenny/gcc-4.1
http://packages.debian.org/lenny/gcc-4.2
http://packages.debian.org/lenny/gcc-4.3

all of the 'list of files' links i've followed from those contain the header.
e.g.
http://packages.debian.org/lenny/sparc/gcc-4.3/filelist
http://packages.debian.org/sid/mips/gcc-4.1/filelist
http://packages.debian.org/squeeze/mipsel/gcc-4.1/filelist


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Start GSServicesManager lazily

[Matt Rice]

On Sat, May 2, 2009 at 2:34 AM, Markus Hitter m...@jump-ing.de wrote:

 Any objections or additional topics about such a change?


the only additional topic i have is that GSServicesManager is (or was)
also used as the ApplicationName DO port, and receives stuff like
application:openFile: when the app is already running and you do
something like gopen foo.ext and the app has registered for .ext.

not really an objection, because its been long enough since i have
looked at the code that i am not sure if your proposal would affect
this though it sounds like it might.

anyhow i think this should continue to work regardless of the
existence of a services menu.


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Fwd: NSView patch

[Matt Rice]

On Mon, Feb 23, 2009 at 8:50 AM, Fred Kiefer fredkie...@gmx.de wrote:
 Matt Rice wrote:
 On Mon, Feb 23, 2009 at 5:50 AM, Fred Kiefer fredkie...@gmx.de wrote:
 The other problem that we sometimes mark subviews as still needing
 display due to rounding errors should be addressed. Here it would be
 helpful to get the detailed values of the involved rectangles. These
 surely are in Matts gdb log, but as he is using a changed version of the
 NSView code it is hard for me to tell, which is which. What would help
 is to have the values of _visibleRect, _invalidRect and aRect at the
 beginning of the method displayRectIgnoringOpacity:inContext:

 the superview at the beginning of the method.

 Breakpoint 2, -[NSView displayRectIgnoringOpacity:inContext:]
 (self=0x276ff90, _cmd=0xdc4e70, aRect={origin = {x = 0, y = 0}, size =
 {width = 476, height = 381}}, context=0x299b740) at NSView.m:2368
 2368      BOOL flush = NO;
 $_invalidRect ={origin = {x = 0, y = 0}, size = {width = 1, height = 1}}
 $_visibleRect ={origin = {x = 0, y = 0}, size = {width = 476, height = 381}}
 $aRect ={origin = {x = 0, y = 0}, size = {width = 476, height = 381}}

 still in the super-view but right before we go to the subview...

 Breakpoint 3, -[NSView displayRectIgnoringOpacity:inContext:]
 (self=0x276ff90, _cmd=0xdc4e70, aRect={origin = {x = 0, y = 0}, size =
 {width = 476, height = 381}}, context=0x299b740) at NSView.m:2450
 2450                  if (NSIsEmptyRect(isect) == NO)
 $_invalidRect ={origin = {x = 0, y = 0}, size = {width = 0, height = 0}}
 $_visibleRect ={origin = {x = 0, y = 0}, size = {width = 476, height = 381}}
 $aRect ={origin = {x = 0, y = 0}, size = {width = 476, height = 381}}
 $isect ={origin = {x = 48.7490425, y = 192.641785}, size = {width =
 118, height = 54}}
 $subviewFrame ={origin = {x = 48.7490425, y = 192.641785}, size =
 {width = 118, height = 54}}

 right after we go
 isect = [subview convertRect: isect fromView: self];

 Breakpoint 4, -[NSView displayRectIgnoringOpacity:inContext:]
 (self=0x276ff90, _cmd=0xdc4e70, aRect={origin = {x = 0, y = 0}, size =
 {width = 476, height = 381}}, context=0x299b740) at NSView.m:2453
 2453                      [subview displayRectIgnoringOpacity: isect
 inContext: context];
 $new_isect ={origin = {x = 0, y = 0}, size = {width = 117.85, height = 
 54}}


 now here in the view where the error occurs

 Breakpoint 2, -[NSView displayRectIgnoringOpacity:inContext:]
 (self=0x284f7e0, _cmd=0xdc4e70, aRect={origin = {x = 0, y = 0}, size =
 {width = 117.85, height = 54}}, context=0x299b740) at
 NSView.m:2368
 2368      BOOL flush = NO;
 $_invalidRect ={origin = {x = 0, y = 0}, size = {width = 118, height = 54}}
 $_visibleRect ={origin = {x = 0, y = 0}, size = {width = 118, height = 54}}
 $aRect ={origin = {x = 0, y = 0}, size = {width = 117.85, height = 54}}

 Breakpoint 1, gsbp () at NSView.m:2362


 Thank you for checking all these values. It is really just a small
 rounding error in the conversion. What about cheating here? For this
 special case the simplest solution would be to use the bounds rectangle
 of the sub view as new isect, when the real isect before the conversion
 is equal to the frame rect of the sub view.
 I know this will not help us in all cases, but it would quite often save
 us the computation of the conversion and in this specific case it is
 also more correct.

 The code would look somewhat like this, plus plenty of comments
 explaining why we do this:

              isect = NSIntersectionRect(aRect, subviewFrame);
              if (NSIsEmptyRect(isect) == NO)
                {
                  if (NSEqualRects(isect, subviewFrame) == YES)
                    isect = [subview bounds];
                  else
                    isect = [subview convertRect: isect fromView: self];
                  [subview displayRectIgnoringOpacity: isect inContext:
 context];
                }

 The main problem here is that somebody will have to convince me that
 this is correct in all cases, even with scaling and rotation.


I don't think that will work because I'm also seeing rounding errors on
the isect = NSIntersectionRect(...) calls... though not in the stuff i
sent earlier for some reason... not sure why...
but that would also only work when displaying whole views,
and i take it you don't like the idea of just using
GSAlmostEqualRects() in NSView?

here's 2 test cases, bar.app is the minimal one and another one that
allows you to drag the purple view around by clicking on it, and
resize it by clicking the black square, rotate and scale and all that
other stuff... (note that scaling doesn't seem to work until its been
rotated)
the one thing it doesn't do is allow you to set the origin at
non-integer increments unless whatever input device your using gives
non-integer coordinates (i don't appear to have one)
if its not reproducable I could add something like a NSStepper to
increment the deal by the value of the value of the top slider or
something

Re: Fwd: NSView patch

[Matt Rice]

 rectangles and point
 coordinates.  However, the nature of an 'appropriate' comparison could
 vary depending on the device/context we are drawing to.  If we are
 working in an abstract 'points' based coordinate system, but that is
 going to be converted to a screen or a printer with a specific
 resolution, we must take care to use appropriate rounding (not so fuzzy
 that the end result is out by a pixcel for instance).

 Should we be using private functions to do fuzzy comparisons rather than
 using NSEqual... functions,
 eg. GSAlmostEqualRects(r1, r2, precision)
 where we adjust the precision depending on the drawing context?

 Or is Matt's solution, with a fixed precision (assumed to be fine enough
 for all real world output devices) better?


 Begin forwarded message:

 From: Matt Rice ratm...@gmail.com
 Date: 23 February 2009 08:57:32 GMT
 To: Richard Frith-Macdonald rich...@tiptree.demon.co.uk
 Cc: GNUstep Developer gnustep-dev@gnu.org
 Subject: Re: NSView patch

 On Sun, Feb 22, 2009 at 10:59 PM, Richard Frith-Macdonald
 rich...@tiptree.demon.co.uk wrote:

 On 22 Feb 2009, at 21:31, Matt Rice wrote:

 On Sun, Feb 22, 2009 at 8:29 AM, Matt Rice ratm...@gmail.com wrote:

 this just makes debugging a bit easier if you guys want it...

 bug #25658 appears to be a bug in the NSView display stuff,
 because some random subset of a views subviews which don't need
 display
 are getting drawRect: called multiple times through _handleAutodisplay
 even though they needs_display = NO;
 with overlapping subviews this causes views which are below other
 views to be drawn above views which are above them.
 and its kind of a pain to debug when this flag is being set all
 over the
 place.


 and here is a fix for the bug i was tracking down

 Please can you explain how this fixes the bug (what the actual bug
 is).  The
 reason I ask is that, though the idea of making NSEqualRects() consider
 slightly different rects to be equal seems fairly reasonable, it does
 not
 seem to be how it's implemented on MacOS-X.
 I found this by writing some tests to determine, by trial and error, the
 largest difference between two constants that was still considered
 equal in
 NSEqualPoints(), NSEqualSizes() and NSEqualRects() on MacOS-X, then
 changed
 the code on GNUstep to make it easy to set a breakpoint and examine the
 actual float values used.  When I did that I found that the point where
 values began to be considered equal was the point where the compiler
 made
 the two constants into identical floats.  ie. MacOS-X seems to be
 doing the
 same as our existing implementation and testing for exact float
 equality.

 If making NSEqualRects() fuzzy about its test for equality fixes your
 problem, perhaps the issue is in the way the function is being used
 somewhere?


 the bug is that in NSView.m ~2400 in my patched version
 the first place that _rFlags.needs_display is set to NO, in
 -displayRectIgnoringOpacity:inContext:
 inside of the if (NSEqualRects(...) == YES) call
 if the 2 rects differ slightly such as 169.996... and 170 the view
 will never be set as not needing display

 then when it gets back to the super-view, a couple of the subviews are
 still marked as needing display
 so it goes through and draws those again, and subviews appear drawn
 outside of the order of _sub_views.
 set with the sortSubviewsUsingFunction:context:

 then when the subviews handle mouse events, the view which receives
 the mouse event is not the view which you appear to be clicking on,
 but a view below it in the _sub_view order
 leading to the behaviour in the screenshot.

 https://savannah.gnu.org/file/dbmodeler_diagram_view.png?file_id=17494
 attached to http://savannah.gnu.org/bugs/?25658

 attached are some gdb logs (sources modified a bit for convenience)
 $1 $2 and $3 are
 aRect, neededRect, and NSUnionRect(neededRect, aRect)
 in that order.

 it also shows the drawRect: being called twice,
 why the actual values slightly differ i hadn't tried to figure out as
 I just figured NSEqualRects should handle it (and pretty much still
 do)
 but I can tell you it is non-deterministic, the same view with the
 same width/height moved to 2 different locations by setting the frame
 origin may cause it to start exhibiting the behaviour even though the
 width/height never changed.

 so it is possible that this may be a common issue but since most views
 do not overlap the multiple calls to drawRect: went unnoticed.
 i'll try reproducing it with Gorm, and see how that goes...






___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: NSView patch

[Matt Rice]

On Mon, Feb 23, 2009 at 8:37 AM, Nicola Pero
nicola.p...@meta-innovation.com wrote:

 unfortunately for our unsuspecting view, subviews which were at some
 odd coordinate were left as needing display,  when their super views
 noticed that they were still marked as needing display and redisplayed
 only those. (in case a view calls -setNeedsDisplay: on something while
 in drawRect:)

 Yes.  This is where there seems to be an error in the logic in the current
 code - ie,
 support for overlapping sibling views is missing.  If a view is redrawn, all
 views
 that above it must always be redrawn too. ;-)

 So, if view A is still marked as needing redisplay, and view B is on top
 of it, both A and B must be redrawn, even if B is not marked as needing
 redisplay.  The current code in the GUI doesn't do that; it iterates over
 the
 subviews, and redraws the ones marked for redisplay, but doesn't redraw
 any other one, without considering that if we support overlapping sibling
 views,
 it also needs to redraw all the other views that are on top of the ones
 being
 redrawn. ;-)

 In the standard situation where there are no overlapping views, adding
 support
 for overlapping sibling views in that way would mean a lot of pointless
 redrawing
 though - because if view A is redrawn, then all views following it in the
 list of subviews
 would be redrawn even if they are not actually overlapping A.  In other
 words,
 any time anything changes in a window, everything needs to be redrawn. :-(

 Presumably the code could try to only redraw views that are over (according
 to the list of views) *and* that overlap the ones that needed to be redrawn.
 I'm not sure how to do that computation efficiently though ... I suppose for
 every view that is redrawn, you also iterate over all the views above it
 looking for ones that overlap, and redraw these as well.  That sounds
 potentially
 expensive (N^2) if there are a lot of subviews ... :-(

 Thanks


Yeah I think that this is something that it shouldn't do as per the
documentation you quoted earlier, but in theory it should work alright
if you are very careful in the views you use,
and make sure those don't set super views as needing display, (though
you could setNeedsDisplayInRect: on the view which contains the
overlapping view alright).

it would never work for something like overlapping
NSBlinking12OClockView  where a digital clock blinks 12:00 on a
timer. though you could allow it to only blink the 'top-most view'
e.g. the key view if you wanted

but the views are in a split view and a scroll view, and most stuff
out there just has one view which encompasses the area

and as I said in the bug report, i'm probably going to remove
overlapping views whenever I get automated graph layout in the diagram
view, and remove the ability to drag them around, I was mostly
investigating this due to the performance implications of drawing
subviews multiple times..


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: [Gnustep-cvs] r27874 - in /libs/gui/trunk: ChangeLog Source/NSCell.m

[Matt Rice]

On Mon, Feb 16, 2009 at 11:50 PM, Matt Rice ratm...@gmail.com wrote:
 On Mon, Feb 16, 2009 at 11:43 PM, Fred Kiefer fredkie...@gmx.de wrote:
 Fred Kiefer wrote:
 I make these changes and you can comment on them.

 It turned out that the patch I made had a big problem. :-)

 The new code in itself was correct, but there is a long standing bug in
 NSButtonCell #11946 (With a reference to the even older #4635). And as
 long as the setXXXTitle: methods on NSButtonCell fall back to
 setStringValue: we cannot use setObjectValue: in the method
 setStringValue: NSCell.
 Looks like we need to fix one bug first before we can work properly on
 the other. For now Riccardo has added a work around that will allow
 NSCell to operate again. In the long run we should be able to remove
 this workaround again.

 Fred

 Hmm, I believe I had a patch for #11946, the problem was I sent out
 patches to various maintainers to fix their usage of setStringValue:
 to setTitle: and succeeded in getting one app fixed (GWorkspace)
 i'll look around for it.


attached and updated to head, not sure if it does what you want,
because it relies on the [super setStringValue:] in -setTitle: and
reimplements -setStringValue: to manage state.

note that in gorm i'm seeing Button in every scroll view's scroller,
which leads me to believe there is something somewhere that should be
using setTitle: in either gorm or gui.. should be easy to track down
with a breakpoint on NSButtonCell setStringValue: i imagine.

not really tested very well.


11946.diff
Description: Binary data
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: [Gnustep-cvs] r27874 - in /libs/gui/trunk: ChangeLog Source/NSCell.m

[Matt Rice]

On Mon, Feb 16, 2009 at 11:43 PM, Fred Kiefer fredkie...@gmx.de wrote:
 Fred Kiefer wrote:
 I make these changes and you can comment on them.

 It turned out that the patch I made had a big problem. :-)

 The new code in itself was correct, but there is a long standing bug in
 NSButtonCell #11946 (With a reference to the even older #4635). And as
 long as the setXXXTitle: methods on NSButtonCell fall back to
 setStringValue: we cannot use setObjectValue: in the method
 setStringValue: NSCell.
 Looks like we need to fix one bug first before we can work properly on
 the other. For now Riccardo has added a work around that will allow
 NSCell to operate again. In the long run we should be able to remove
 this workaround again.

 Fred

Hmm, I believe I had a patch for #11946, the problem was I sent out
patches to various maintainers to fix their usage of setStringValue:
to setTitle: and succeeded in getting one app fixed (GWorkspace)
i'll look around for it.


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Allowing Applications to continue after exception...

[Matt Rice]

On Wed, Feb 4, 2009 at 11:14 AM, Richard Frith-Macdonald
rich...@tiptree.demon.co.uk wrote:

 On 4 Feb 2009, at 18:53, Gregory Casamento wrote:

 In some cases on Mac OS X I have observed that exceptions which are not
 fatal on Mac sometimes ARE fatal on GNUstep.   I believe we should change
 the logic which deals with exceptions to add a continue button and only
 show the panel when the application is running in debug mode.   This would
 allow the application to continue when recovery is possible.

 Does anyone have any thoughts on this?

 I think the panel is shown when there is an UNCAUGHT exception.
 If the exception has not been caught, there is nowhere to return to and no
 way to continue ... so adding a continue button and returning from the
 uncaught exception handler would not allow the application to continue.

 If you want an exception to not be fatal, you have to write code to handle
 it and continue.

 Sometimes you might think you can continue running, but know that the app
 probably won't be doing what the user expects.  In this situation it makes
 sense to display an alert panel explaining the nature of the problem, and
 allow the user to choose between continuing and cleanly terminating.  This
 however is a very different case from the panel shown when the uncaught
 exception handler is called.



there might be an handler in the NSApplication -run method which
allows the runloop to continue iterating...
i seem to recall an old version of openstep doing something to this
effect with uncaught exceptions, didn't show a panel, or NSLog
anything, or abort unless of course i was using NSAssert, and it was
doing something with the c preprocessor to get rid of my NSAsserts,
which seems possible :)


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Allowing Applications to continue after exception...

[Matt Rice]

On Wed, Feb 4, 2009 at 9:50 PM, David Ayers ay...@fsfe.org wrote:
 Am Mittwoch, den 04.02.2009, 23:52 -0500 schrieb Gregory Casamento:
 The attached test program does not crash on Mac OS X when the button
 is pressed, but does crash on GNUstep.  The button calls the action:
 method in Controller which immediately throws an exception.

 I believe this confirms that GNUstep's behavior is inconsistent with
 Cocoa.   I can test on OpenStep, but I suspect that the behavior is
 the same there as it is on Cocoa.

 FWIW, IIRC this inconsistency was intentional an I believe for a very
 good reason.  I thought we had documented it at the time but I can't dig
 it up easily right now.

 An uncaught exception indicates that the application is in an undefined
 state.  For certain type of applications (like viewers) this can be
 ignored.  For editor application this could mean that the document being
 edited could be corrupted and saving it cause data corruption.

 This thread is the only reference I found in which we suggested some
 type of Developer-Mode which indicates that I know what I'm doing,
 let me debug, will you?!.

 http://lists.gnu.org/archive/html/discuss-gnustep/2004-10/msg00092.html

 I still believe that handling generic handling of exceptions in the
 runloop is a dangerously wrong and an implementation detail that we
 shouldn't try to be compatible with.  But others may disagree.

I definitely agree with this, but wanted to toss out another point of
view in the same vein
in an editor application, say that there is an exception when working
with a single document
(i'm seeing something in DBModeler when closing certain documents
which I haven't managed to fix yet unfortunately)

so i'm getting an exception when an error occurs in a single document,
but the entire application crashes, now i should probably add some
exception handling somewhere (not exactly sure where, probably all
over the place...) to my app but haven't figured out where yet, but
until I do, an exception in a single document means that all open
documents close, and could potentially lose changes in other unsaved
documents which are open.


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: _control_view stuff...

[Matt Rice]

On Tue, Oct 28, 2008 at 3:43 AM, Matt Rice [EMAIL PROTECTED] forgot
to attach the patch.


_control_view.diff
Description: Binary data
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: _control_view stuff...

[Matt Rice]

On Tue, Oct 28, 2008 at 3:43 AM, Matt Rice [EMAIL PROTECTED] wrote:

 i've always thought of cells the other way, views tell them when/where
 and what to draw, so the idea of the cell having its setStringValue:
 method called, and then telling the view that it should redraw the
 cell seems fairly weird to me

sorry to reply to myself (again) but i forgot some stuff/found some
better documentation,

from the documentation of the controlView method here

http://docs.sun.com/app/docs/doc/802-2112/6i63mn60o?l=jaa=view#01.Classes-8

For example, the subclasses of NSActionCell defined by the
Application Kit invoke this method in order to
send the NSControl a message such as updateCellInside:.

so that to conflict with the idea setStringValue: is doing something
wrong by calling the -updateCell method (ignoring the inside part
since either would lead to the segfault)...

another idea is that drawWithFrame:inView: could reset the
_control_view on exit but that seems counter to the documentation that
-controlView returns the view in which the cell was last drawn...


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: NSPropertyListSerialization fails with OpenStepFormat on OSX

[Matt Rice]

Fred Wrote:..
 From the name of the format in the error message I gather that you are
 complaining about an Apple bug here. Is this correct?

no its really a feature of them deprecating the openstep style plists,
at some point writing worked for legacy apps (as shown by the example
link Dave posted),
and then at some point it appears they have removed it allowing only
to read legacy and write xml plists...

if you look here it is clearly deprecated..

http://developer.apple.com/documentation/Cocoa/Reference/Foundation/Classes/NSPropertyListSerialization_Class/Reference/Reference.html

quote:
Important: The NSPropertyListOpenStepFormat constant is not supported
for writing. It can be used only for reading old-style property lists.

On Sun, Oct 26, 2008 at 2:07 PM, David Wetzel [EMAIL PROTECTED] wrote:
 David Wetzel wrote:

  add [+NSPropertyListSerialization 
  dataFromPropertyList:format:errorDescription:]
  to base-additions, call the Apple implementation if format != 
  NSPropertyListOpenStepFormat
  if code runs on Apple.

 What I cannot understand is your proposed solution to this problem. We
 should replace the method in the GNUstep extensions, but still call the
 Apple version of the same method in some cases? There may be way to do
 this, but this is clearly a dangerous proposal.

 Why? It will do the same like on a GNUstep or OPENSTEP system.

I think Fred's 'clearly a dangerous proposal.' mostly is coming from
the fact that in order to override a method with the category and then
call the original implementation will require runtime hacking through
method swizzling, and overrides intended noon-functionality of their
foundation...

http://www.cocoadev.com/index.pl?MethodSwizzling

It may be worthwhile to think of a less invasive (not to mention
easier) change, of just exposing the GNUstep implementation of
NSPropertyListSerialization as GSPropertyListSerialization and adding
it to base-additions then using that in gdl2


 Wouldn't it be easier to just convert property lists written on new Macs
 to be used on old installations of EOModeler? GNUstep should be able to
 do that conversion.

 I want to run DBModeler.app on OSX and read + write .eomodeld files in a 
 format all original
 EOModelers understand. Otherwise DBModeler is useless.

 http://developer.apple.com/documentation/Cocoa/Conceptual/PropertyLists/Articles/OldStylePListsTa
 sk.html


yeah, that works with GNUstep but there is also old WebObjects
installations which predate xml plists entirely

let me just add another slightly related tidbit here
https://savannah.gnu.org/bugs/?22364

DBModeler is also in the same position as cenon I think, it is wanting
the old style plists when NSValue's etc were encoded as strings
it looks like if we used NSPropertyListSerialization we might be able
to get rid of the places when we encode where we manually convert
everything to strings, and we could go back to just encoding NSValue's
which might clean up that code a bit too..

as it is, the code dates back from when there was 'one plist format to
rule them all.', which predates NSPropertyListSerialisation, and when
the GNUstep plist format was changed, we just coaxed the code into
encoding the correct object types that it expects to find...

anyhow, i'm pro reliable way to write old openstep style plists.


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: NSTableView editing problem [Was: Next stable release?]

[Matt Rice]

On Sun, Jun 8, 2008 at 10:57 AM, Fred Kiefer [EMAIL PROTECTED] wrote:
 I was completely wrong here. The problem is at a totally different place.
 Look at the code in NSTextFieldsCell that Nicola changed a few months ago:


Ahh, yes changing the below fixes it here i was confused because it is
asked to redraw the edited cell frame, but in the case that it is, the
code is doing what it should by not redrawing.


 - (void) drawInteriorWithFrame: (NSRect)cellFrame inView:
 (NSView*)controlView
 {
  /* Do nothing if there is already a text editor doing the drawing;
   * otherwise, we draw everything twice.  That is bad if there are
   * any transparency involved (eg, even an anti-alias font!) because
   * if the semi-transparent pixels are drawn over themselves they
   * become less transparent (eg, an anti-alias font becomes darker
   * and gives the impression of being bold).
   */
  if (([controlView respondsToSelector: @selector(currentEditor)] == NO)
  || ([(NSTextField *)controlView currentEditor] == nil))
{
  if (_textfieldcell_draws_background)
{
  if ([self isEnabled])
{
  [_background_color set];
}
  else
{
  [[NSColor controlBackgroundColor] set];
}
  NSRectFill([self drawingRectForBounds: cellFrame]);
}

  [super drawInteriorWithFrame: cellFrame inView: controlView];
}
 }

 This basically means that a text field cell will only draw itself, when
 there is no editor for the containing control view. This is nice and fine,
 when the text field cell is the only cell of a text field, but in the matrix
 and table view case this stops all the cells in the controller from drawing
 themselves while there is an editor.

 How to get of this trap? We could check if the cell is the selected cell of
 its control view and only then not draw it in the editing case. This may
 work as a table view has no clear notion of a selected cell and so all cells
 will still get drawn, whereas matrix and normal control handle this
 correctly.

 Another possibility is to move the don't draw check into the control view.
 This looks better to me. A cell should always draw itself when asked to do
 so, the decision should be put somewhere else.


that seems alright to me, and appears to be what drawRow:clipRect: in
NSTableView is already doing. i've looked at the bug report that code
was added for but didn't have any luck reproducing it with the fix
disabled...

 Any better ideas out there?


no but thanks for looking into this.


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Next stable release?

[Matt Rice]

On Fri, Jun 6, 2008 at 12:32 PM, Fred Kiefer [EMAIL PROTECTED] wrote:
 Matt Rice wrote:

 I did notice an NSTableView bug though, and its reproducable afaict
 with any editable tableview if you edit a field after editing its row
 never set as needing display, you have to click a row to get things to
 redraw.


 Matt,

 I did not quite understand this description (Did you mean cell where you
 wrote row?), but if you have a fix for this, it surely is welcome.


no, i meant if you double click a cell, then type something and hit
enter or tab keys

after that the whole row is not redrawn (except for the field editor)
and sometimes the whole tableview is blanked out the behaviour changes
on different apps.

I think we can kind of rule out NSTableView I tested the last known
version that I know worked

(r24478 of -make,base,gui,back) and that worked still...

then i tested the svn head versions of make,base,gui,back
with the r24478 version of NSTableView and that produced the same results.

NSTableView drawing right now is fairly susceptible to attacks by
things setting it as needing display besides itself.

see NSTableView.m (-drawRect:)

it blanks out the background of the entire rect
with

[self drawBackgroundInClipRect:aRect];
and highlights the selection then draws the grid.

but if you look at -drawRow:clipRect:

if (i != _editedColumn || rowIndex != _editedRow)
   {
  does drawing stuff..
   }

this code is fairly old and uncommented what i recall it doing is
not drawing the edited row or column because it doesn't want to draw
over top of the field editor.

anyhow from the same version of NSTableView both working and not
working it seems as though NSTableView doesn't set the edited row rect
as needing display but either the field editor, or NSTextFieldCell or
something else maybe is setting it as needing display that is my
guess... anyways

i've tried it with the cairo backend and the art backend
you can reproduce it with gorm by going

document-new application,
select NSFirst
select 'Classes' from the toolbar
in the attributes inspector, select actions
add a few actions
edit the action name.
hit enter


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Next stable release?

[Matt Rice]

On 6/6/08, Fred Kiefer [EMAIL PROTECTED] wrote:
 Richard Frith-Macdonald wrote:

 On 5 Jun 2008, at 20:11, [EMAIL PROTECTED] wrote:

 Following on David's email,  It's been over a year since we last
 branched a stable release.  Should we try to do another one soon?

 I guess so.

 I really wanted to get base much more compatible with the latest MacOS-X
 before doing another stable release, but I just haven't had the time to
 do any real work on that, so realistically it's not worth waiting.

 I don't see any reason at all not to make a new stable release of
 gui/back, but perhaps Fred knows differently.


 A new stable release is fine for me. I think the current code is far
 better then the 0.12 release and I don't see any mayor incompatibility
 change coming up in the near future.
 There is one thing I should do before a new back release, that is test
 with cairo 1.6.4 to see how to avoid the black bars that have been
 reported. I hope to do this on the weekend, after that a release should
 be possible.
 Just one more question: Are we all confident that the big changes I made
 to NSWindow and GSLayoutManager are now stable enough? They work
 perfectly for me, but that isn't a real test.


I just wanted to chime in that these fixes exposed a bug in DBModeler,
before things were leaking, the fixes showed that in some
implementation of -dealloc we were iterating over an array while a
method called from dealloc had been changed to modify the array.
after fixing that everything appears to be working fine for it.

I did notice an NSTableView bug though, and its reproducable afaict
with any editable tableview if you edit a field after editing its row
never set as needing display, you have to click a row to get things to
redraw.


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: GPLv2 licensing issues

[Matt Rice]

On Mon, Apr 14, 2008 at 7:07 AM, Yavor Doganov [EMAIL PROTECTED] wrote:
 В Fri, 11 Apr 2008 18:42:15 -0400, Hubert Chathi написа:

  On Fri, 11 Apr 2008 09:08:52 + (UTC), Yavor Doganov [EMAIL PROTECTED]

  or http://price.sourceforge.net/exception.html
  

  What problems do you see with it?

  IMVHO such an exception *might* fix one side of the problem, but the
  resulting combined work still violates LGPLv3, which in turn is GPLv3
  with additional permissions.


YAVHO
but I thoght that the (l)gplv2 conflicted with the (l)gplv3 and not
the other way around
due to the no additional requirements portion of the (l)gplv2 and the
additional requirements of the (l)gplv3
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Fwd: GPLv2 licensing issues

[Matt Rice]

doh


-- Forwarded message --
From: Matt Rice [EMAIL PROTECTED]
Date: Thu, Apr 10, 2008 at 12:35 PM
Subject: Re: GPLv2 licensing issues
To: Fred Kiefer [EMAIL PROTECTED]


On Thu, Apr 10, 2008 at 12:16 PM, Fred Kiefer [EMAIL PROTECTED] wrote:
  I am still not sure whether this problem actually exists. As far as I
  understand the GPL it only transfers to libraries that are statically linked
  to it. GNUstep base, gui and back (normally) get linked dynamically and to
  my understanding this should not cause any problem. But I surely am no
  expert on this matter.

 http://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins

 If the program uses fork and exec to invoke plug-ins, then the
 plug-ins are separate programs, so the license for the main program
 makes no requirements for them.


 
   It also may be different for the objc runtime, again not sure how you
  normally link it in. And of course application linking with GPLv2 libraries
  will need a detailed inspection.
 

 libobjc contains an exception

 /* As a special exception, if you link this library with files compiled with
   GCC to produce an executable, this does not cause the resulting executable
   to be covered by the GNU General Public License. This exception does not
   however invalidate any other reasons why the executable file might be
   covered by the GNU General Public License.  */


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: GSOC: desktop integration

[Matt Rice]

On Sat, Mar 22, 2008 at 12:02 PM, Hubert Chathi [EMAIL PROTECTED] wrote:
 Hi all,

  I'm looking at applying for Google's SOC this year.  I'm interested in
  looking at GNU/Linux desktop integration issues.  So I'd like to look
  at:
  - the window focusing issues, and making GNUstep work well in all window
   managers

I think this is a good idea, though I am wondering the scope of your
intent, e.g. to make gnustep usable with sloppy focus, or to fix
issues with click-to-focus, or both

i think these are separate issues so maybe you could elaborate a bit.


  - looking at which freedesktop.org standards it would make sense for
   GNUstep to implement
  - looking at providing bindings/interfaces for some freedesktop.org
   software (e.g. dbus is mentioned on the wiki)
  - although not exactly desktop-integration work, I could also look at
   bitmap image reading/writing support

  Does this sound like a worthwhile project?  What scope would be
  reasonable for GSOC?  Are there other things I should be looking at?


as far as other things

one more idea is finishing up the update to the latest xdnd
specification, and filling in the missing conversions so we can drag
and drop between gnustep and X apps

http://freedesktop.org/wiki/Specifications/XDND

Fred can probably elaborate more on what is done and needs to be done
with this though.


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: gdb objc regressions

[Matt Rice]

On Mon, Mar 10, 2008 at 12:07 AM, David Ayers [EMAIL PROTECTED] wrote:
 Hello Matt

  Matt Rice schrieb:


   there is some issues with debugging objc
  [snip]

  A current workaround would be to:

  set language objective-c

  explicitly, as suggested by Daniel.

  I haven't had the resources to investigate the exact commit that caused
  the regression yet.


I just figured out why and will send a patch to the correct list,
an omission from dwarf2read.c:set_cu_language.


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: case sensitivity in make flags

[Matt Rice]

On Mon, Mar 10, 2008 at 3:18 PM, Nicola Pero
[EMAIL PROTECTED] wrote:

  But as you very correctly point out, that makes lot of sense for variables
  which are lowercase (eg, debug=yes, messages=yes, strip=yes), but is not
  really natural for variables that are uppercase - eg, 
 xxx_HAS_RESOURCE_BUNDLE=yes,
  where obviously it comes more natural to write xxx_HAS_RESOURCE_BUNDLE=YES. 
 :-(


I think you missed the point i was actually trying to make, the point
was that my makefile had been
in GNUstep cvs and working for a long time, and then the case of the
flag changed, and my
subproject then began lacking resources.


  Anyway, other suggestions or comments welcome

  I believe that Adam is doing a gnustep-make stable release soon, so I 
 wouldn't want
  to make changes to subversion until he's done - so no hurry :-) - but it 
 will get
  done.


because this behaviour has changed it might break existing makefiles
(it actually already has)
I would prefer that the change DO make it into the release. so IMHO hurry :P

I have changed the GNUmakefile in question, because i'm not sure if
this change of behaviour has made it into a previous release.


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: case sensitivity in make flags

[Matt Rice]

On Mon, Mar 10, 2008 at 4:46 PM, Nicola Pero
[EMAIL PROTECTED] wrote:

   I think you missed the point i was actually trying to make, the point
   was that my makefile had been in GNUstep cvs and working for a long time,
   and then the case of the flag changed, and my subproject then began lacking
   resources.

  Ahm - thanks, I see what you mean now :-)

  The issue is related, but slightly different.  Your GNUmakefile always had
  xxx_HAS_RESOURCE_BUNDLE=yes, until David changed it to YES on 2008-03-06. ;-)

  gnustep-make has always accepted yes for the xxx_HAS_RESOURCE_BUNDLE flag,
  since its first introduction in 2002. :-)

  But I suspect David was confused by the fact that xxx_NEEDS_GUI (a new flag)
  requires YES instead of yes - which actually does sound like a bad
  idea (since it's inconsistent with everything else!) and might be worth
  fixing before the release! ;-)

  So I'll fix the new xxx_NEEDS_GUI flag to accept yes instead of YES, like
  everything else.  Well, maybe I'll have it accept both yes and YES for 
 now.


This is good to hear, i was worried we had gotten into a situation
where certain releases
only accepted YES, and others only accepted yes, so it was impossible
to be compatible
with all versions of gnustep-make.


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

case sensitivity in make flags

[Matt Rice]

in gdl2/DBModeler/Inspectors/GNUmakefile

it sets a flag
Inspectors_HAS_RESOURCE_BUNDLE=YES

this has ceased to work changing it to

Inspectors_HAS_RESOURCE_BUNDLE=yes

fixes it, but should this be case sensitive?


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

gdb objc regressions

[Matt Rice]

Hi,

there is some issues with debugging objc

GNU gdb Fedora (6.7.50.20080227-2.fc9)
GNU gdb 6.8.50.20080309-cvs

the 6.7.1 release doesn't seem to have these issues...

we can set a breakpoint on a method, so thats good.

Breakpoint 1, -[EOEntity attributes] (self=0x8937df0, _cmd=0x6e9210)

you cannot naively print an instance variable

(gdb) po isa
No symbol isa in current context.

though po in general works,
(gdb) po self.isa
EOEntity

also sending messages to an object doesn't work,

(gdb) p [self class]
A syntax error in expression, near `[self class]'.

it appears these are covered by failures in the testsuite but i
anticipate not alot of gdb developers have the objc compiler
installed,

I don't mind looking into this but it may take me a while to get up to speed,
so any pointers in where to start looking would be appreciated

matt


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: gnustep base on NetBSD 4.0 i386

[Matt Rice]

On Jan 6, 2008 6:02 AM, Richard Frith-Macdonald
[EMAIL PROTECTED] wrote:

 On 6 Jan 2008, at 10:41, David Wetzel wrote:

 OK ... so errno 0 means that the operating system is not reporting
 any error ... supporting the idea that the thread detach is succeeding.


pthread functions return an error code, so no need to set errno, if it
did set errno wouldn't you have to lock it every time so another
thread didn't overwrite it, unfortunately this stuff just gets lost in
objc_thread_detach.

  Possibly what you are seeing is an objc runtime bug such that the
  detach succeeds but appears to fail because the thread ID is zero?
  See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18573
 

I don't believe this is it this time, after testing the pthread
library i've yet to see it return a thread id of 0
though at this point it is not possible to definitively say

  No idea. Do you have a test program for that?

 Nope ... I guess you would need to build the runtime with debug, so
 you could step through into the runtime method to detach the thread,
 and see what thread Id the underlying call is returning, and what
 error status it is returning.

I did this which is where i came up with -pthread it was failing in
the call to __gthread_active_p()
in __objc_thread_detach from posix.h iirc,
which looks for the symbol pthread_cancel,
but of course it still fails when passing -pthread to the stock compiler/libobjc
so at this point i'm stuck wrt getting it working or figuring out
whats wrong with the stock compiler

and can only offer work arounds such as using the libobjc from
gnustep, or building a compiler which works when -pthread is passed


 Anyway, it looks like you probably have a gcc/runtime problem rather
 than an gnustep problem.  You could try to confirm that by writing a
 little test program to detach a thread using the objc api directly
 and not linking with any gnustep stuff.
 eg. something like

it seems to me objc_thread_detach is kind of broken
it can fail in multiple ways and only has 1 error code (NULL)
and that error code conflicts with a non-failure on certain platforms
because it is merged with the thread id.

it'd be nice if it accepted an address to a thread id as an argument
and returned an error code, like pthreads


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: some testing of base on sparc 64

[Matt Rice]

could this be related to

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18573

On Jan 2, 2008 3:00 PM, David Wetzel [EMAIL PROTECTED] wrote:

 Hi,

 I did some testing on a Sparc64 running NetBSD 4.0

 It seems like threads are not working here. We should have some automated
 test script that runs this in
 the test farm script.

 --
 David Wetzel


 ___
 Gnustep-dev mailing list
 Gnustep-dev@gnu.org
 http://lists.gnu.org/mailman/listinfo/gnustep-dev


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Getting to 1.0 for gui

[Matt Rice]

On Nov 10, 2007 7:08 AM, Gregory John Casamento [EMAIL PROTECTED]
wrote:

 All,

 I'd like to have a discussion and come to a consensus on what everyone
 feels would comprise a 1.0 gui release.

 Please let me know your thoughts on the matter.


i hadn't seen mentioned the postscript  pdf output from NSViews e.g.
-dataWithEPSInsideRect:/-dataWithPDFInsideRect:

this may be working as it has been a long time since i tried it but when i
did, I seemed to only get a portion of the view (though the portion looked
alright)

though it may have been in a clip view, i cannot recall if it was in one or
not

anyhow things may have changed since then I don't know, none the less
I'd consider well tested postscript output 1.0 release worthy,
pdf would be also nice, but at least one of the two

almost forgot chaos inhibitors, without them, 1.0 is simply unattainable.
and once those are in place we can make our slogan
GNUstep now with 20% more real chaos inhibitors.
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: NSMutableDictionary requires NSCopying?

[Matt Rice]

On 2007-03-19 02:43:36 -0800 Richard Frith-Macdonald [EMAIL PROTECTED] 
wrote:




On 19 Mar 2007, at 10:24, Michael Gardner wrote:

To use a custom key type with NSMutableDictionary, I defined -hash 
and
-isEqual: but not -copyWithZone:, since the NSDictionary docs say 
that

keys are retained rather than copied. But when I try to insert a key
of that type, I get an NSInvalidArgumentException saying that my 
class
does not recognize -copyWithZone:. If I add that method, the 
exception

goes away and everything works fine. I've tried this on both the
latest GNUstep release and on trunk. Are the docs just out-of-date?


Yes, the documentation is just wrong. Dictionary keys do need to be  
copied.


I've fixed the documentation (at least, all the errors I spotted) in  
svn 
trunk to say that keys are copied.




possibly worthwile to explain why things are copied and not retained,
if you add a mutable object to a dictionary and subsequently modify 
the object
in a way which modifies the objects -hash value, it would become 
inconsistent

with the hash value stored in the dictionary.



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: gnustep-make experiment

[Matt Rice]

On 2007-02-16 11:25:49 -0800 Matt Rice [EMAIL PROTECTED] wrote:


On 2007-02-15 12:44:18 -0800 Adam Fedor [EMAIL PROTECTED] wrote:


On Feb 15, 2007, at 7:35 AM, Gregory John Casamento wrote:



Have we even tried, experimentally, doing this refactoring to see  
if it
actually would make things simpler?   The best way to prove a point 
is

code.  I would like to see if it can be done.

While I understand it's not *strictly* needed for FHS  
compliance. it 
is something that many developers, outside of  GNUstep, use on a 
daily 
basis.


If someone can produce a patch which would simplify gnustep-make  
that 
uses pkg-config, I really don't see a reason not to consider  
including 
it.


I don't really see the point of this.  It might be nice to support 
pkg-config for those who want it, but pkg-config doesn't even come  
close 
to supporting the requirements of GNUstep development. First,  
pkg-config 
is only for developers.  Maybe it would be useful for  writting a 
few tools 
and such using GNUstep, but for anything more  complicated?  Why 
would a 
developer want to used all the advanced  capabilities of the GNUstep 
envirnoment AND want to write all their  Makefiles from scratch 
using 
pkg-config? Seems counter-productive.


As Nicola said, it doesn't even simply things, either.



well attached is a patch anyways which implements a step-config 
program in c,
it is very similar to pkg-config, but provides a c api and some 
output formats
make has been modified to output a file gnustep-config.make so 
step-config 
only
needs to be run once... gnustep.cfg unlike gnustep.conf is required 
GNUstep.sh has

been modified to run step-config instead of the other way around

This patch is against yesterdays svn so its possibly a little bit out 
of date


a few things to note, it defers to the environment, so if GNUstep.sh 
wants to 
set

something like library-combo etc, it should pick that up

GNUstep.sh doesn't really want all variables just some of them, so i 
still 
need to add

support for outputting multiple specified variables

then GNUstep.sh just needs to go -x foo -x bar for all the variables 
it does 
want.

and it currently doesn't clean gnustep-config.make.



oops forgot to add gnustep.cfg.in

gnustep.cfg.in


gnustep.cfg.in
Description: Binary data
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: gnustep-make experiment

[Matt Rice]

On 2007-02-16 12:04:14 -0800 Nicola Pero 
[EMAIL PROTECTED] wrote:


This patch rewrites some internal code (making it more complex, not 
more easy,
but I suppose it's a matter of taste) and the only visible effect I 
can see 
is that it destroys the non-flattened (ie, fat binary) support in 
gnustep-make. :-(


Fat binaries *will* be/are supported in gnustep-make v2, and given 
all the 
effort that was
spent to keep that very difficult feature working across massive 
changes in 
going from
gnustep-make v1 to gnustep-make v2, I do want it to be clearly 
advertised and 
marketed. :-)


No way we're dropping it right now once all the work has been 
completed and 
we're on track

with gnustep-make v2.



No that should still work..

GNUSTEP_HEADERS_DIRS/GNUSTEP_HEADERS_FLAGS and the libraries 
counterparts


is either set to ${GNUSTEP_HEADERS_DIRS_FLATTENED} or
${GNUSTEP_HEADERS_DIRS_NON_FLATTENED}

this stuff just no longer needs to be handled inside of make.



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: gnustep-make experiment

[Matt Rice]

forgot to cc the list on this... and added some stuff


On 2/16/07, Nicola Pero [EMAIL PROTECTED] wrote:


 No that should still work..

Hard to believe.


Ok yeah I probably did break something with the gnustep-make patches,
but this *is* just
a prototype, and this does not mean it cannot be made to work..

from what I tested, I was able to compile gnustep-base as a fat binary.



So you're compiling a C tool and then hope to use
the compiled executable without change on all the cpu/os that we support ?




Just tried on mingw, and it fails to compile because of a lack of strsep,
that should be easy to to fix.


We managed to get rid of all C tools in gnustep-make in October 2006, and
that
was a good step in terms of simplification: no longer having to worry about
the location of tools in fat binary dirs when using gnustep-make's own
tools,


this is expected to be in the PATH, there is no need for that


cross-compilation issues simplified (and hopefully cleared out at some point
in the future), and a package that you drop somewhere there is a shell and a
make system and it just works.  I already told you in private that I don't
think
adding back C tools to gnustep-make is a good idea - for me it's like going
backwards
in time to a more complicated setup.


I just don't see the point in this, without a c tool we have to
rewrite the same code
in sh, make, c/objc, and csh and have autoconf replace stuff in a ton
of files...
if you add 1 variable you have to modify all these... seems needlessly
complicated
when a c tool would suffice.


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: gnustep-make experiment

[Matt Rice]

On 2/16/07, Nicola Pero [EMAIL PROTECTED] wrote:

Matt, thanks for your comments.

I understand your desire to centralize the configuration, but there
is an actual reason why GNUstep.sh is a pure shell script. ;-)

It's a machine-independent program that can be in a machine-independent
directory
and that can then be used to bootstrap the fat binary system. :-)



Yes, my take is, people using weird configurations should not mind doing
weird things GNUstep.sh can still set up the achitecture specific
environment variables
for 'step-config' to then use.

non-flattened configurations must then continue sourcing GNUstep.sh.


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: gnustep-make experiment

[Matt Rice]

On 2007-02-12 10:30:57 -0800 Nicola Pero 
[EMAIL PROTECTED] wrote:


pkg-config works best if compile/link flags are fixed and listed in a 
file.


The compile/link flags in gnustep-make are determined dynamically 
instead, 
they are not fixed.


This is possible with pkg-config, you can reference external variables 
with

--define-variable=foo=bar so you could pass the architecture in from
gnustep-make.

You can have non-flattened multi-platform installations that are 
mounted from 
the network; the same gnustep-make will then use different 
compilation 
flags/tools for the different hosts (keep in mind that each host 
might also 
have a different
filesystem configuration, eg, they could be sharing a network-mounted 
System 
domain,

while having different domains in different locations).


this is also possible if you split up the .pc files one for each 
domain configuration

then the different hosts can configure their PKG_CONFIG_PATH's to
different search orders so each machine/user gets different 
configurations for different.





___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: gnustep-make experiment

[Matt Rice]

On 2007-02-12 18:59:06 -0800 Nicola Pero 
[EMAIL PROTECTED] wrote:


Because we don't even store fixed 
sets of flags, but we compute them dynamically, using pkg-config to 
print 
them is more of an additional problem

than a solution.


I forget exactly how non-flattend looks having not used it since the 
default changed...

but heres an example of a dynamic -L for a specific architecture

$ pkg-config --define-variable=host_os=linux-gnu 
--define-variable=host_cpu=ix86 --libs-only-L gnustep
-L/System/Library/Libraries/linux-gnu/ix86 
-L/Local/Library/Libraries/linux-gnu/ix86


because it is only a file, is a benefit because it forces you to keep 
your logic separated from all the flags.





___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: gnustep-make experiment

[Matt Rice]

On 2007-02-11 04:47:50 -0800 Nicola Pero 
[EMAIL PROTECTED] wrote:



so can we change everything to

GNUSTEP_MAKEFILES ?= $(shell gnustep-config.sh GNUSTEP_MAKEFILES)
include $(GNUSTEP_MAKEFILES)/common.make


I think it's a good suggestion, even if I'd change it (slightly) to be

ifeq ($(GNUSTEP_MAKEFILES),)
GNUSTEP_MAKEFILES := $(shell gnustep-config.sh GNUSTEP_MAKEFILES)
endif
include $(GNUSTEP_MAKEFILES)/common.make



i'm wondering why?

the first works if GNUSTEP_MAKEFILES is unset.
the second works if GNUSTEP_MAKEFILES is unset or empty.

include $(GNUSTEP_MAKEFILES)/common.make
would never have worked in either case, i'd rather fix case 1 and
consider case 2 a broken build environment.

unless this is about = vs := where there exists nothing like :?=

and I think the first one is alot easier to remember/easier on the 
eyes.




___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: gnustep-make experiment

[Matt Rice]

On 2007-02-11 05:02:53 -0800 Matt Rice [EMAIL PROTECTED] wrote:

unless this is about = vs := where there exists nothing like :?=


this seems to be the case how := only execute the $(shell) a few times 
instead of

once per time $(GNUSTEP_MAKEFILES) is used



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: gnustep-make experiment

[Matt Rice]

On 2007-02-11 05:00:20 -0800 Nicola Pero 
[EMAIL PROTECTED] wrote:




I like the idea of your patch, so I rewrote the shell script and 
committed 
it.



Minor nit... isn't gnustep-config.sh meant to be executed, not 
sourced?

So shouldn't it be named gnustep-config instead of gnustep.config.sh?


Yes, it is meant to be executed, not sourced.  Not sure what 
implication

that does have on the '.sh' at the end of the name though.

Maybe omitting the '.sh' would allow us more freedom in the future, 
eg,

to replace the script with a compiled binary if we ever need ?

Any suggestions/comments on what the best name is ?



definately prefer gnustep-config for the above reasons



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: gnustep-make experiment

[Matt Rice]

On 2007-02-11 03:23:35 -0800 David Ayers [EMAIL PROTECTED] wrote:

Nicola Pero schrieb:

So how does is help with writing configure scripts?
Maybe something like?

GNUSTEP_MAKEFILES=${GNUSTEP_MAKEFILES:=`gnustep-config 
GNUSTEP_MAKEFILES`}

if test -z $GNUSTEP_PATHLIST; then
   . ${GNUSTEP_MAKEFILES}/GNUstep.sh
fi



Yes, I think gnustep-config still needs to go a bit further and add

GNUSTEP_CFLAGS
GNUSTEP_CPPFLAGS
GNUSTEP_LDFLAGS
and possibly some more stuff

as we still need to hard code the obsoleted 
-I$GNUSTEP_SYSTEM_ROOT/Library/Headers, etc
I assume this will happen when --includedir/--libdir/--bindir etc, etc 
are supported as per

the TODO in common.make:264

And then, once all the variables are set, how should we write 
configure

script tests?  (and which variables are we allowed to use?)

Should we
1) tweak the environment to allow AC_CHECK_LIB to work?
2) create our own:
- AC_CHECK_GNUSTEP_LIBRARY
- AC_CHECK_GNUSTEP_FRAMWORK
- AC_CHECK_GNUSTEP_NATIVELIBRARY
macros to be included in configure.ac scripts via GNUSTEP_MAKEFILES?
3) invoke 'make' with gnustep makefiles in some config subdirectory
during ./configure
4) other ideas which I may have missed?


It definately seems the autoconf way to check system capabilities 
regardless of
platform, if one takes this stand AC_CHECK_NATIVELIBRARY seems out of 
place

and you should call both
AC_CHECK_GNUSTEP_LIBRARY and
AC_CHECK_GNUSTEP_FRAMEWORK

I don't feel strongly either way

though about naming conflicts e.g. libInterfaceBuilder vs 
InterfaceBuilder.framework

If we theoretically promote libInterfaceBuilder to a native-library

and take in to account the different ways people use GNUstep-make on 
apple

a) using gnustep
b) just using gnustep-baseadd/make

theres currently no way to stop gcc from looking in 
/System/Library/Frameworks etc
(well i believe there is in gcc svn) we can just add 
/path/to/GNUstep/System/Library/Frameworks

to the beginning with -F option

and if its found it'll link against the GNUstep one... before looking 
in system places
runtime is probably a whole other deal requiring environment variables 
and stuff


but yeah 1) and 2) look good
or a combination of 1) + AC_CHECK_FRAMEWORK used to implement 2)



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: gnustep-make experiment

[Matt Rice]

On 2007-02-10 05:20:45 -0800 Fred Kiefer [EMAIL PROTECTED] wrote:


Wim Oudshoorn schrieb:

Matt Rice [EMAIL PROTECTED] writes:

On 2007-02-09 09:18:02 -0800 Wim Oudshoorn [EMAIL PROTECTED] 
wrote:

So next I tried to download pkg-config version 0.21 and compile it
(on
MS Windows). Of course that failed because I hadn't installed glib.
So
I gave up.  (I tried once to get glib compiled on windows and it
wasn't a pleasant experience.)

It does not require anything but a reasonably well working C 
compiler

and a C library,
but can use an installed glib if that is present.


Well, did you actually try compiling pkg-config?  I did not 
investigate 
deeply but the suggested way of compiling:


./configure
make

Did not work.  ./configure succeeded splendidly, but make
failed and the reason was that glib.h could not be found.

But I don't want to start a discussion in the GNUstep mailing lists 
on
how to install pkg-config.   I just wanted to see how it would work 
on 
windows.





Second, I like the idea of using more standard tools in the GNUstep
configuration and compilation process. pkg-config could come in rather
nicely here. But I don't quite understand, how it could be used as a
replacement for GNUstep.conf. Not that I like the role GNUstep.conf is
currently playing in GNUstep, but this is clearly different from what
pkg-config is normally doing. GNUstep.conf is a file that gets 
accessed

each time a GNUstep application is run to find out about the various
GNUstep settings. It is there to allow GNUstep installations to be 
moved
to arbitrary places after compilation. pkf-config is by its intention 
a

compile time tool. It looks for include paths and libraries and such
stuff. It is not supposed to be around when a compiled application or
libraries is run.



Yes, someone pointed out the gnustep.pc and GNUstep.conf files
duplicate information, and then the discussion went to
gnustep libraries could also be tought to read gnustep.pc directly
without pkg-config to replace gnustep.conf, so we don't have to add a
runtime dependency but i admit, this is stretching pkg-config
and abnormal usage.

but personally I was fine with the duplicate information
as they do different things, gnustep.pc for compile time and
gnustep.conf for runtime.

actually most of this information was auxiliary and wasn't even
used by GNUstep-make only GNUSTEP_MAKEFILES was used.

I initially thought it was required, but it is not with Nicolas recent 
changes to svn.

but the rest should stay for things unable to use gnustep-make


Third, Nicola keeps on claiming in this thread that a standard GNUstep
could be compiled by just setting the values in GNUstep.conf and doing
nothing else. This does not work for me, I still need to source
GNUstep.sh to get things working. Otherwise the compilation of gui
complains that it cannot find the base library. This is not too bad, I
am used to this behaviour. I just wanted to scale back some claims 
made

here.



I actually haven't tried this but i assume you set GNUSTEP_MAKEFILES?
I don't believe Nicola actually said that, he said you don't have to 
source

GNUstep.sh, only set GNUSTEP_MAKEFILES.

I'd assume you must have set GNUSTEP_MAKEFILES otherwise i'd expect
it to bail out before including common.make... strange


Last, I would expect that a standard GNUstep should even run without a
GNUstep.conf file being set up. It may be easier for people who love 
to

move things to have a template file that they only need to change. But
do we really have to install this template already?



not sure about this one



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: gnustep-make experiment

[Matt Rice]

On 2007-02-10 09:27:32 -0800 Nicola Pero 
[EMAIL PROTECTED] wrote:




a quick test of a makefile executing pkg-config 1000 times takes 
about 6 
seconds..
say there are 5 invocations of pkg-config per invocation of make... 
thats 
200 make processes.


Wow - that would be a massive overhead ... for just reading config 
(ie, doing 
nothing

useful, only bootstrapping)! ;-)

I thought in the worst case scenario you'd run 1 pkg-config 
invocation per 
makefile -- that
would be pretty bad already since you're doubling the number of 
processes 
executed when
typing 'make' in an already built tree; but if you plan on adding 5 
per 
makefile invocation,
then you're almost multiplying by 6 the overhead of the building 
system.  In 
practice

it will be less than that, but a x2 or x3 sounds perfectly plausible.



Yes there would only be one, unless we wanted to get rid of 
GNUstep.conf entirely
then there would be about 5... you had reservations that GNUstep.conf 
and gnustep.pc
contained duplicate information... since theres no way to get what i'm 
trying to achieve from
GNUstep.conf, the only way around that would be to move everything in 
there to gnustep.pc.


thats where the 5 per makefile invocations come from.

If we retain GNUstep.conf and add gnustep.pc we only need 1...

I consider that unacceptable considering we don't gain anything in 
functionality, and

the improvement in 'standardization' is extremely doubtful.


Of course we don't gain anything,
getting rid of GNUSTEP_MAKEFILES isn't anything...
ability to get information about GNUstep from the shell isn't anything

if we want a decent -config system, we're going to reimplement 
pkg-config...
on my system i have over 300 pkg-config enabled libraries... and i'm 
glad I 
don't have

300 foo-config scripts in my $PATH.


They are different things ... GNUstep has got a single config script 
for 
everything.

We don't install a config file for each library.



This was an attempt to state that if everyone created their own 
-config system
which if GNUstep.sh/environment variables goes away i strongly believe 
we

need. I would have 300 -config systems on my machine.

If you are obsessed with using pkg-config for GNUstep, then it would 
make 
sense to
install a pkg-config config file for each library that we install ... 
so you 
would have
a pkg-config configuration for libgnustep-base, libgnustep-gui, etc.  
Then 
people using
pkg-config instead of gnustep-make to build their software could at 
least use 
them in

the way they are intended to be used.

Still, I can't see any advantage in using pkg-config instead of 
gnustep-make, 
so I don't
really understand why anyone would want to do that.  You'd be on your 
own in 
the nightmare
of how to compile or link your framework on all different machines 
and 
platforms.





that is not what i'm trying to do I'm attempting to *USE* 
pkg-config

WITH gnustep-make not instead of. pkg-config does not replace
configure/make even on gnome/gtk it provides a way to query information
about the installed packages for use WITH make.

I think this would be a step in the right direction but everybody 
has 
already been down

that road and since then switched to pkg-config.


I don't see the parallel.

We are following a completely different road than everyone else - we 
have a 
centralized, standardized building system, a centralized, 
standardized core 
ObjC API, a centralized,
standardized GUI API, and everything else is built ordinately on top 
of that 
by the

same organized building system. ;-)



at the possibility of repeating myself It is not always possible to 
use gnustep-make.
configure scripts and plugins for existing projects with existing 
build systems..


without environment variables, or a -config system there is no way to 
build a

GNUstep enabled gnuplot without converting its entire build system to
GNUstep-make this wouldn't fly.

Other people don't have that.  Each library is built in a different 
way and 
installed
in the different way with different options; each library is using a 
different subset
of libc and other system libraries, which vary a lot between 
different 
systems; it's
a mess with millions of non-standard flags and locations and conf 
options and 
system

dependent flags to determine and use. :-(

So, some of them figured out they'd put each library's flags into 
some common 
format

to put some order in the mess.  Fine.

But we don't have that problem.  We have organized and standardized 
everything.  Our system
is certainly unusual, but well-organized and laid out.  It's a 
pleasure to 
write your
quick GNUmakefile listing what goes into your library, knowing that 
you don't 
have to
do anything and it will just work on GNU/Linux/*BSD/Windows/Apple.  
The usual 
libc/compatibility/flags nightmare does not exist in our organized 
world.


So saying that we're going through the road of everyone else is 
inaccurate to 
say the least.
We're not planning to have a config 

Re: gnustep-make experiment

[Matt Rice]

On 2007-02-10 11:48:55 -0800 Richard Frith-Macdonald 
[EMAIL PROTECTED] wrote:


I haven't followed this in particular detail, and I haven't looked at 
 the 
actual work you have done, so I might well be missing some points  or 
misunderstanding ... sorry, just haven't had time.


First I'll say how I think pkg-config could be useful for GNUstep.
Then I'll address points in your email from the perspective of your  
apparent 
desire to use pkg-config to replace the existing  GNUstep.conf stuff.




I actually don't care about replacing GNUstep.conf at all
I see how in certain cases you could(?) want to relocate GNUstep 
without
recompiling GNUstep, and I consider this a highly niche situation, or 
override

configuration options for a precompiled GNUstep installation.
I consider *THIS* a niche situation... I can see how you might want to 
do it
but... it aint a bad thing... but it seems such an uncommon practice I 
don't even
see why we are arguing modifying 2 files is harder than 1 file for 
something very
few libraries provide, and very few users will attempt. Add to this 
that you'd only have
to modify 2 files .pc and .conf when the *developer* changes his build 
system.


Nicola or someone.
had reservations that GNUstep.pc contained duplicate information 
already stored
in GNUstep.conf.  I admit... using pkg-config to replace GNUstep.conf 
does not look
like a good idea and is not the direction i'd want to take it.. but it 
would be possible.


I think it would be nice for external (ie not basically ObjC/GNUstep  
code) 
packages to be easily able to link with GNUstep libraries and  
frameworks 
without using gnustep-make.  That is, to be able to easily  get 
command line 
arguments for all dependencies of a library rather  than just the 
library 
location.
This is a low priority niche requirement as few packages will want to 
 link 
with ObjC/GNUstep code unless they are ObjC/GNUstep packages  
themselves, in 
which case the many advantages of gnustep-make mean  that a 
reasonable 
developer would just just gnustep-make anyway.


Agreed this actually was not the motivation behind the idea but is an 
added benefit.

for getting rid of GNUSTEP_MAKEFILES.



If we are going to provide this facility then, as it's only for a  
tiny 
minority of users, we can reasonably require them to install/use  
another 
package such as pkg-config (I don't think we could justify  imposing 
such a 
requirement otherwise).


The obvious thing to do then is modify gnustep-make such that, when  
it 
builds a library, framework, or bundle, it also generates a pkg- 
config 
metadata file so that we can install that metadata file with  the 
library/bundle/framework and people can use pkg-config to link it  in 
to 
their project.  This in no way implies that gnustep-make or  
makefiles which 
use gnustep-make should ever make use of this  metadata (it's 
probably 
unnecessary for them and undesirable to make  gnustep makefiles 
depend on 
another external program), but having the  metadata files there for 
external 
projects would be really good.
If this means that gnustep-make stores some redundant data, I don't  
think 
that's any problem, we aren't talking about a lot of space here.





Seems we're trying to comprimise with something neither you not I want 
:P

All GNUstep software has the same flags except the -l...
This would be more standard for each lib to have a .pc
but I don't consider it neccesary


On 10 Feb 2007, at 18:23, Matt Rice wrote:



I consider that unacceptable considering we don't gain anything in 
functionality, and

the improvement in 'standardization' is extremely doubtful.


Of course we don't gain anything,
getting rid of GNUSTEP_MAKEFILES isn't anything...
ability to get information about GNUstep from the shell isn't 
anything


Well, Nicola already pointed out how to get rid of  GNUSTEP_MAKEFILES 
... so 
pkg-config doesn't add anything there, and  we already can get 
information 
about GNUstep from the shell, so pkg- config doesn't offer anything 
there 
either.




Yes it does add something... I can configure GNUstep to install into 
/some/random/path

and pkg-config would work without setting GNUSTEP_MAKEFILES.
It provides a single set of instructions for configuring a GNUstep 
build environment.


no if its installed in a standard location just type 'make', otherwise 
set GNUSTEP_MAKEFILES
to the path where you installed GNUstep. (where did my distro install 
GNUstep the user asks?)


if we want a decent -config system, we're going to reimplement 
pkg-config...
on my system i have over 300 pkg-config enabled libraries... and  
i'm 
glad I don't have

300 foo-config scripts in my $PATH.
They are different things ... GNUstep has got a single config  
script for 
everything.

We don't install a config file for each library.


This was an attempt to state that if everyone created their own - 
config 
system
which if GNUstep.sh/environment variables goes away i strongly  
believe we

need. I

Re: gnustep-make experiment

[Matt Rice]

On 2007-02-10 11:48:55 -0800 Richard Frith-Macdonald 
[EMAIL PROTECTED] wrote:


The current setup was particularly designed to 'play nice with the  
rest of 
the world'.
You can't get much nicer than a file in a standard location which  
both the 
shell and makefiles can use.   A pkg-config file on the  other hand 
does 
*not* play nice with the reset of the world.   It  can't be used 
except on 
systems where pkg-config is installed or  where software is specially 
written 
to read it.



It seems to me that GNUstep.conf and pkg-config have rather different 
purposes.  GNUstep.conf is distinctly more universal/portable which  
is 
critical for its intended use of relocating software and  controlling 
options.  On the other hand pkg-config metadata is  convenient for 
getting 
command line flags but no good when pkg-config  is not installed.  So 
I like 
pkg-config as an option for external  use, but not as a dependency... 
I'm in 
favor of gnustep-make storing  the info it needs redundantly so that 
our 
makefiles can run reliably  but people can use pkg-config externally.


I often need to build gnustep-base and proprietory software which  
uses it on 
solaris (and sometimes windows) systems that I don't  own ... and the 
fewer 
packages I have to install to do it, the better.




The 'dependency' on pkg-config is exagerated actually... if pkg-config 
is not installed

as i somewhere in this thread suggested

GNUSTEP_MAKEFILES ?= $(shell pkg-config --variable=makefiles)
include $(GNUSTEP_MAKEFILES)/common.make

you could just set GNUSTEP_MAKEFILES and be done with it.

that line is functionally equivalent to
ifeq ($(origin GNUSTEP_MAKEFILES), undefined
  GNUSTEP_MAKEFILES = $(shell pkg-config --variable=makefiles)
endif

and if you tried to ./configure something which required the gnustep 
pkg-config support

you'd get an error that pkg-config wasn't found in the configure.log

this was so that new makefiles could work with old gnustep-make 
versions

but is equally usable with new gnustep-makes without pkg-config.



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: gnustep-make experiment

[Matt Rice]

On 2007-02-10 17:35:44 -0800 Nicola Pero 
[EMAIL PROTECTED] wrote:


I like the idea of your patch, so I rewrote the shell script and 
committed it.


Thanks!



so can we change everything to

GNUSTEP_MAKEFILES ?= $(shell gnustep-config.sh GNUSTEP_MAKEFILES)
include $(GNUSTEP_MAKEFILES)/common.make

or something like the makefile include path, (though i prefer the 
above)


this was the original intention of my patch, to make it possible to 
not set any GNUstep

specific environment variables and just have make work.

I understand that now makefiles *CAN* but will it be the standard 
practice




___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: gnustep-make experiment

[Matt Rice]

On 2007-02-10 17:34:59 -0800 Nicola Pero 
[EMAIL PROTECTED] wrote:




The only objection i've heard from gnustep.pc is Its not the way 
GNUstep 
stores information.


Here is a refresher --

1. it adds an external dependency upon which *everything* would depend



an entirely optional dependency, people could continue sourcing 
GNUstep.sh.



2. it is slower



-make is not a bottleneck...
for example on my machine
-make building base here takes 2 minutes 3 seconds...
make when base is already built takes 2 seconds..
where adding this stuff to make would be 0.006th of a second per 
invocation of pkg-config/gnustep-config


this argument is hogwash.


3. it is designed for something else (which adds complexity)


It does exactly the same thing gnustep-config.sh does.
that adds no complexity...

4. it requires rewriting and redesigning stuff with no clear 
advantages




there are clear advantages...
now I can add stuff to configure for things *using* gnustep-make which 
attempts to see if

GNUstep libraries exist.

there could be a way to bootstrap gnustep-make to just work without 
any gnustep specific

environment variables.

The objection i have with GNUstep.conf is it isolates gnustep from 
the rest 
of the world.


I find that objection vague.  Can you explain the practical meaning of
it isolates gnustep from the rest of the world ?


It's a text file in /etc/GNUstep.conf containing something like



it can be set by --with-config-file when configuring make.
If this is done, GNUstep can find GNUstep.conf without setting
GNUSTEP_CONFIG_FILE... GNUSTEP_CONFIG_FILE is
provided to override the location of /etc/GNUstep.conf if you
didn't change the default GNUstep.conf location.

I refuse to rely on a feature which
a) 99% of the time is fine.
b) the 1% of the time works unless your relying on GNUstep.conf being 
findable


theres no way to reliably locate it if the caller was not generated by 
GNUstep-make's

configure script.


GNUSTEP_SYSTEM_ROOT=/usr/GNUstep/System
GNUSTEP_LOCAL_ROOT=/usr/GNUstep/Local

It's not like we're designing a massive new language to use in the 
config 
file.  We

have a sequence of key=value lines in a plain text file.



Thats all fine and dandy if it can be located.

Editing GNUstep.conf is something that should be very unusual, but if 
it 
happens,
it shouldn't be very difficult.  It's just a plain key=value text 
file!




that is why i don't understand the need to refrain from duplicate 
information in GNUstep.conf and

gnustep.pc

if you are relocating a build environment (should be much more unusual 
than GNUstep.conf requiring being changed)

modify gnustep.pc and GNUstep.conf
otherwise modify GNUstep.conf

not very difficult



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: gnustep-make experiment

[Matt Rice]

On 2007-02-10 20:46:30 -0800 Christopher Armstrong 
[EMAIL PROTECTED] wrote:




Considering some of the effort needed to get pkg-config working on
Windows, could we please maintain all existing build methods in
gnustep-make? IMHO pkg-config still feels like a alpha quality 
programme

in some environments, despite being widely used. The classic
gnustep-make build environment is still my first choice and is alot
easier to install as it has no unusual or difficult dependencies.


Yes somewhere in this thread backwards compatibility with old 
GNUstep-makes was

discussed and it was stated that one could add

GNUSTEP_MAKEFILES ?= $(shell pkg-config --variables=makefiles)
include $(GNUSTEP_MAKEFILES)/common.make

and create makefiles which work with old GNUstep-makes which weren't
pkg-config enabled this same mechanism can be used to subvert the
pkg-config dependency by manually setting GNUSTEP_MAKEFILES
or sourcing GNUstep.sh

Anyhow now we have gnustep-config.sh which works similarly to 
pkg-config without the optional

dependency...

Its definately up in the air though whether this will become a 
recommended addition to

GNUmakefiles or not...



Lastly, on a slightly unrelated note, the GNU dependencies (zlib,
libpng, libjpeg, etc) that are needed to compile GNUstep on Windows 
can

be automated using an installer from the gnuwin32.sf.net project which
downloads most of the precompiled GNU environment. I was thinking that
it may be possible to take the scripts given there, combine them with
scripts for installing mingw/msys and create an installable mingw
environment on Windows that is ready to compile source code within.

Regards
Chris





___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: gnustep-make experiment

[Matt Rice]

On 2007-02-08 20:29:50 -0800 Nicola Pero 
[EMAIL PROTECTED] wrote:




If we had gnustep-make depend on pkg-config, then you wouldn't be  
able to 
use GNUstep unless you installed pkg-config first.


That's not entirely correct. GNUstep can be taught how to read 
pkgconfig-format-file, such as GNUstep.pc, thus eliminating the need 
 for 
GNUstep.conf entirely,


We designed the GNUstep.conf syntax so that it can be very 
efficiently read

from makefiles, shells, and C/ObjC code.

The 'pkg-config' meta-file format can not be read easily from 
makefiles 
without
firing off a subprocess.  We'd then need to fire off an additional 
subprocess

for each invocation of make, which, performance-wise, is bad.



a quick test of a makefile executing pkg-config 1000 times takes about 
6 seconds..
say there are 5 invocations of pkg-config per invocation of make... 
thats 200 make processes.

This is a drop in the bucket.

all that make does is execute subprocesses.  And this seems to be an 
argument against

-config in general.



PS: I must be missing your point completely because I don't really 
understand 
what you're
trying to say.  Technically, you're suggesting we depend on the 
gnome/gtk 
config
tools (which were not designed for us, so the integration would be 
massively 
painful)

just for the sake of being more similar to gnome/gtk.



pkg-config is not strictly a gnome/gtk tool (it may have originated 
there i'm not sure)
it is used by many non-gnome projects openssl and xorg are not 
gnome/gtk


-config files in general have been embraced by libraries in general 
long before
pkg-config came about, and it saves libraries from polluting the path 
with a ton of,
-config scripts and generally provides a better -config than software 
creating their own.


if we want a decent -config system, we're going to reimplement 
pkg-config...
on my system i have over 300 pkg-config enabled libraries... and i'm 
glad I don't have

300 foo-config scripts in my $PATH.

in fact theres libxml2, openssl, cairo, libpng, libxslt, audiofile, 
portaudio,

libart, freetype all possible gnustep dependencies from our howto page
all which have embraced pkg-config.

so out of the 16 potential deps listed there, more than half support 
pkg-config.


But I suspect what you'd really want to discuss is how to compile 
things 
without
using gnustep-make.  Which is a perfectly valid discussion, and in 
that 
context
pkg-config might make sense.  If you want to build using the 
autoconf/automake/pkg-config toolchain, then using pkg-config is an 
interesting option.




No I believe that he is saying is that pkg-config can be a dependency 
for gnustep-make
and at runtime gnustep can read the .pc file directly. and avoid a 
runtime dependency

on pkg-config.

the patch I posted also only had a gnustep-make dependency on 
pkg-config but since it
kept gnustep.conf if you wanted to modify gnustep.conf you also had to 
modify gnustep.pc


The most obvious option is provide a gnustep-config tool that will 
output the 
gcc flags
for the various stages/types of compilation, and provide some basic 
indication of where
to install things, then you could at least compile and install tools 
and 
libraries without gnustep-make.  We could make it reasonably similar 
to the 
traditional xxx-config gnome/gtk
tools if you think that would make it easier to use.  We can think 
about that.


I think this would be a step in the right direction but everybody has 
already been down

that road and since then switched to pkg-config.



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: gnustep-make experiment

[Matt Rice]

On 2007-02-08 05:13:32 -0800 Nicola Pero 
[EMAIL PROTECTED] wrote:


So we could have a small makefile fragment, let's call it find- 
gnustep.make,
that searches for gnustep-make on disk and sets GNUSTEP_MAKEFILES  
to the 
best
match.  I'll write that makefile fragment, and it will be  
maintained 
inside

gnustep-make.


I don't get this one, you want to let the fragment search for 
gnustep- 
make? Where will it search? Isn't it expensive to search all  
locations 
everytime? I'm not convinced that this can happen  automagically.


Here is an example -- put this at the top of your GNUmakefile, just 
before 
include $(GNUSTEP_MAKEFILES)/common.make --


GNUSTEP_MAKEFILES = $(word 1, \
$(wildcard /usr/GNUstep/System/Library/Makefiles) \
$(wildcard /var/lib/GNUstep/System/Library/Makefiles) \
$(wildcard /usr/local/GNUstep/System/Library/Makefiles) \
$(wildcard /opt/GNUstep/System/Library/Makefiles) \
$(wildcard /System/Library/Makefiles))



This doesn't actually fix anything, if we're going to change the 
GNUmakefiles so their usable without
having environment variables we might as well fix it for all cases not 
just the most common ones.




___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: gnustep-make experiment

[Matt Rice]

On 2007-02-09 05:27:39 -0800 Richard Frith-Macdonald 
[EMAIL PROTECTED] wrote:




On 9 Feb 2007, at 13:04, Matt Rice wrote:

On 2007-02-08 05:13:32 -0800 Nicola Pero [EMAIL PROTECTED] 
innovation.com 
wrote:


So we could have a small makefile fragment, let's call it find- 
gnustep.make,
that searches for gnustep-make on disk and sets  
GNUSTEP_MAKEFILES  to 
the best
match.  I'll write that makefile fragment, and it will be   
maintained 
inside

gnustep-make.
I don't get this one, you want to let the fragment search for  
gnustep- 
make? Where will it search? Isn't it expensive to search  all  
locations 
everytime? I'm not convinced that this can happen   automagically.
Here is an example -- put this at the top of your GNUmakefile,  
just 
before include $(GNUSTEP_MAKEFILES)/common.make --

GNUSTEP_MAKEFILES = $(word 1, \
$(wildcard /usr/GNUstep/System/Library/Makefiles) \
$(wildcard /var/lib/GNUstep/System/Library/Makefiles) \
$(wildcard /usr/local/GNUstep/System/Library/Makefiles) \
$(wildcard /opt/GNUstep/System/Library/Makefiles) \
$(wildcard /System/Library/Makefiles))


This doesn't actually fix anything, if we're going to change the 
GNUmakefiles so their usable without
having environment variables we might as well fix it for all cases  
not 
just the most common ones.


I don't think there *is* a fix for all cases.



Yeah, i agree with that... not exactly what I meant though.
I meant pkg-config would work if one wanted to install GNUstep 
somewhere

non-standard.

I'd certainly much rather have a solution which works for all common  
cases 
(as Nicola suggests) than have a dependency on external stuff  like 
pkg-config which definitely won't work on some platforms unless  we 
install 
it as additional software when installing GNUstep.   Installing 
pkg-config 
with GNUstep is not a big issue in itsself, but  then you get 
problems if 
someone else installs a version configured  to look in a different 
place for 
its data files.




Either they can tell pkg-config where to find it with PKG_CONFIG_PATH 
or
they can configure GNUstep to tell it where to put the .pc file.. I 
wouldn't think
GNUstep should be installing pkg-config anyways.  if its a compile 
time dependency only

so distributing binaries thered be no risk of this.

It seems to me that using pkg-config would be more fragile than what  
Nicola 
suggests, but would be fine to include as a fallback to try  when all 
else 
fails.




Not really... both either they work or you have to configure it,
its home-brew configuration process or more standard one.
his solution also doesn't fix the other issue with finding the libdir 
from autoconf.


I don't really like the idea of using pkg-config as a fallback... 
because of the potential for
people who understand pkg-config attempting to configure gnustep with 
PKG_CONFIG_PATH and
find out its not falling back to using pkg-config...  divergent paths 
of configuration


anyhow i guess i will come up with a patch to use a gnustep-config 
which gets its information from

GNUstep.conf and we can argue over that...
(in other words reimplement pkg-config for GNUstep)
I just don't think we should disregard existing tools/processes 
lightly.




___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: gnustep-make experiment

[Matt Rice]

On 2007-02-09 08:41:29 -0800 Adam Fedor [EMAIL PROTECTED] wrote:



On Feb 9, 2007, at 8:48 AM, Matt Rice wrote:



anyhow i guess i will come up with a patch to use a gnustep-config  
which 
gets its information from

GNUstep.conf and we can argue over that...
(in other words reimplement pkg-config for GNUstep)
I just don't think we should disregard existing tools/processes  
lightly.




Sure that's true, but remember that these tools are all for non- 
standard 
systems.  Whenever I think about a change to the GNUstep  system, I 
think 
first about how it will affect the standard, and I  mean ideal  
system, 
that we are working towards (e.g. one with a  nice working 
ProjectCenter, 
etc). Neither GNustep.conf nor  PKG_CONFIG_PATH  would really be 
needed in 
the standard installation.  Developers always want to do something 
unusual, 
so we should make it  POSSIBLE for them to do whatever they want, but 
it's 
not required to  make it easy for them to do it.





well heres a quick hack on that... only lightly tested
just add
GNUSTEP_MAKEFILES ?= $(shell gnustep-config --makefiles)
include $(GNUSTEP_MAKEFILES)/common.make

obviously gnustep-config needs to change wrt recent changes to make/FHS
 stuff just not sure what those changes are yet.

foo.diff
Index: configure.ac
===
--- configure.ac(revision 24410)
+++ configure.ac(working copy)
@@ -224,6 +224,21 @@
 AC_SUBST(GNUSTEP_CONFIG_FILE)
 
 #-
+# location of gnustep-config path 
+#-
+
+AC_MSG_CHECKING([gnustep-config path location])
+AC_ARG_WITH(config-bindir,[
+--with-config-bindir=PATH
+The location to install the gnustep-config binary],
+GNUSTEP_CONFIG_BIN_DIR=$withval,GNUSTEP_CONFIG_BIN_DIR=no)
+if test $GNUSTEP_CONFIG_BIN_DIR =  -o $GNUSTEP_CONFIG_BIN_DIR = no; 
then
+GNUSTEP_CONFIG_BIN_DIR=/usr/local/bin/;
+fi
+AC_MSG_RESULT($GNUSTEP_CONFIG_BIN_DIR)
+AC_SUBST(GNUSTEP_CONFIG_BIN_DIR)
+
+#-
 # Now read/import the existing configuration file, if any
 #-
 
@@ -1060,7 +1075,7 @@
 #
 AC_CONFIG_FILES([config-noarch.make config.make openapp opentool 
 executable.template GNUmakefile GNUstep.conf GNUstep.sh GNUstep.csh fixpath.sh
-gnustep-make.spec])
+gnustep-make.spec gnustep-config])
 AC_CONFIG_COMMANDS([default],
[[chmod a+x openapp opentool fixpath.sh executable.template]],
[[]])
Index: gnustep-config.in
===
--- gnustep-config.in   (revision 0)
+++ gnustep-config.in   (revision 0)
@@ -0,0 +1,58 @@
+#!/bin/sh
+
+if [ $# -lt 1 ]; then 
+echo $0: argument required.;
+fi
+
+# Determine the location of the system configuration file
+if [ -z $GNUSTEP_CONFIG_FILE ]; then
+  [EMAIL PROTECTED]@
+fi
+
+# Determine the location of the user configuration file
+if [ -z $GNUSTEP_USER_CONFIG_FILE ]; then
+  [EMAIL PROTECTED]@
+fi
+
+# Read the system configuration file
+if [ -f $GNUSTEP_CONFIG_FILE ]; then
+  . $GNUSTEP_CONFIG_FILE
+fi
+
+# Read the user configuration file ... unless it is disabled (ie, set
+# to an empty string)
+if [ -n $GNUSTEP_USER_CONFIG_FILE ]; then
+  case $GNUSTEP_USER_CONFIG_FILE in
+/*) # An absolute path
+if [ -f $GNUSTEP_USER_CONFIG_FILE ]; then
+  . $GNUSTEP_USER_CONFIG_FILE
+fi;;
+ *) # Something else
+if [ -f $GNUSTEP_HOME/$GNUSTEP_USER_CONFIG_FILE ]; then
+  . $GNUSTEP_HOME/$GNUSTEP_USER_CONFIG_FILE
+fi;;
+  esac
+fi
+
+
+case $1 in --makefiles)
+   echo $GNUSTEP_SYSTEM_ROOT/Library/Makefiles;
+   exit
+   ;;
+--system-root)
+   echo $GNUSTEP_SYSTEM_ROOT
+   exit
+   ;;
+--local-root)
+   echo $GNUSTEP_LOCAL_ROOT
+   exit
+   ;;
+--network-root)
+   echo $GNUSTEP_NETWORK_ROOT
+   exit
+   ;;
+--user-root)
+   echo ~/$GNUSTEP_USER_DIR
+   exit
+   ;;
+esac
Index: GNUmakefile.in
===
--- GNUmakefile.in  (revision 24410)
+++ GNUmakefile.in  (working copy)
@@ -141,7 +141,8 @@
$(makedir)/Master \
$(makedir)/Instance \
$(makedir)/Instance/Shared \
-   $(makedir)/Instance/Documentation)
+   $(makedir)/Instance/Documentation \
+   @GNUSTEP_CONFIG_BIN_DIR@)
$(EC)(echo Installing GNUstep configuration file in 
$(GNUSTEP_CONFIG_FILE); \
 $(srcdir)/mkinstalldirs $(GNUSTEP_CONFIG_FILE_DIR); \
 $(INSTALL_DATA) GNUstep.conf $(GNUSTEP_CONFIG_FILE))
@@ -159,7 +160,8 @@
  $(INSTALL_PROGRAM) -m 755 GNUstep.csh $(makedir); \
  $(INSTALL_PROGRAM) -m 755

Re: gnustep-make experiment

[Matt Rice]

On 2007-02-09 09:18:02 -0800 Wim Oudshoorn [EMAIL PROTECTED] wrote:



Hm, I just read part of this discussion.  Apparently pkg-config is a 
very 
popular tool for

finding dependencies etc.   Also it seems to be used
by plenty of libraries and people, although I never encountered
it in practice.  For me a .pc is probably a mystery.
So before forming an opinion on pkg-connfig integration with
gnustep-make I would like to read up a little on pkg-config.
However the only thing I quickly found was a wiki page:

http://pkgconfig.freedesktop.org/wiki

And beside a link to download section and a list of supportd platforms
there seems to be no documentation for pkg-config at all.  Obviously 
that is 
because I do not look in the right place.


Another thing that caught my eye was the dependency on glib, I have 
had some 
bad experiences with glib on windows.


So next I tried to download pkg-config version 0.21 and compile it (on
MS Windows). Of course that failed because I hadn't installed glib.  
So

I gave up.  (I tried once to get glib compiled on windows and it
wasn't a pleasant experience.)



It does not require anything but a reasonably well working C compiler 
and a C library,

but can use an installed glib if that is present.

(from the page you linked).


Moral of the story, if someone want to add pkg-config, better make
it a smooth experience.   I for one don't want to spend a lot of time
installing another tool with intricate dependencies just to be able
to compile my own application.

Wim Oudshoorn.





___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

NSOutlineView display optimization

[Matt Rice]

wrt reloadItem:reloadChildren: redisplaying all the rows

saw this discussed 
athttp://savannah.gnu.org/bugs/?func=detailitemitem_id=9487


this seems to work... not sure what happens if the item isn't in the 
outline view

it might want to test that...

also, not sure how much of an optimization it would be... could see 
rowOfItem: being rather slow
on large outline views as it has to isEqual: every item in the _items 
array...


foo.diff

Index: NSOutlineView.m
===
--- NSOutlineView.m (revision 24482)
+++ NSOutlineView.m (working copy)
@@ -449,6 +449,7 @@
   id object = (item == nil) ? (id)[NSNull null] : (id)item;
   NSArray *allKeys = NSAllMapTableKeys(_itemDict);
   NSEnumerator *en = [allKeys objectEnumerator];
+  NSRect rectOfItem, rectOfLastRow;
 
   expanded = [self isItemExpanded: item];
 
@@ -485,8 +486,19 @@
  [self _openItem: dsobj];
  [self noteNumberOfRowsChanged];
}
-}  
-  [self setNeedsDisplay: YES];
+} 
+  
+  rectOfItem = [self rectOfRow:[self rowForItem:item]];
+
+  if (reloadChildren  expanded)
+{
+  rectOfLastRow = [self rectOfRow:_numberOfRows - 1];
+  [self setNeedsDisplayInRect:NSUnionRect(rectOfItem, rectOfLastRow)];
+}
+  else
+{
+  [self setNeedsDisplayInRect: rectOfItem];
+}
 }
 
 /**
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev