Okay, I just got this mail from yogi and since it is related to the
problem, I do now forward it to the ml.
Cheers,
Nils Kneuper aka Ivanovic
Original-Nachricht
Betreff:Editor-icon problem
Datum: Thu, 24 May 2007 07:24:55 +0200
Von:Hinrichs, Joerg [EMAIL PROTECTED]
Hi Nils,
On Thu, May 24, 2007 at 08:17:51AM +0200, Nils Kneuper wrote:
Okay, I just got this mail from yogi and since it is related to the
problem, I do now forward it to the ml.
it seems you made an error forwarding this mail:
The information contained in this e-mail is confidential. It
Am Donnerstag 24 Mai 2007 schrieb Eric S. Raymond:
Ivanovic, myself, alink, and allefant have all been whacking at this
problem but have failed to solve it. There is a suggestion on the
table that we ought to drop a nuke on the problem by linking the
Boost filesystem library and using its
after a quick look at the website...
* it's not GPL (might be GPL-compatible, but I havn't checked)
* any thought from our tiny-GUI guys ? how large is boost ? what mem
requirements does it have...
* it seems to provide the same type of functionalities than SDL...
* I couldn't find anything about
Am Donnerstag 24 Mai 2007 schrieb jeremy rosen:
* it's not GPL (might be GPL-compatible, but I havn't checked)
It is compatible and used by other (L)GPL projects like OpenOffice.org
The license is like that für libstdc++ - the goal is to be usable by everyone.
* any thought from our tiny-GUI
On Thursday 24 May 2007 15:00:25 David Philippi wrote:
* it seems to provide the same type of functionalities than SDL...
Boost is to C++ what CPAN is to Perl just with much higher quality
requirements. It got founded by members of the C++ standard comitee and its
primary goal is to explore
I can't really work on this bug (no time and I am on linux) but here is some
other infos.
IIRC the planned design on _main.cfg is, when its presence is detected, to
skip other files and directories. These files are then loaded by includes in
the _main.cfg. So, not detecting the special status of
On Thu, May 24, 2007 at 02:12:16PM +0200, jeremy rosen wrote:
I also would like to add boost and for more things than filesystems
only.
Last, including a new library is a long and delicate process
* Long: well, with the breakage of the Editor, we can either release
1.3.3 with a known broken
Recently there was a discussion on IRC and it seems zipios is no longer
used. If it's really not used is there still a need to keep it?
If we agree to remove it I don't mind to do that job.
Regards,
Mark de Wever aka Mordante/SkeletonCrew
___
On Thu, May 24, 2007 at 05:54:19PM +0200, Alink wrote:
An other possible cause of this bug, is the ugly path//file.cfg which we
can see in the logs. I don't know if there is OS difference (or in file
functions implementations) to handle these //, but it's a risk. Btw, about
this, an other
Mark de Wever [EMAIL PROTECTED]:
Recently there was a discussion on IRC and it seems zipios is no longer
used. If it's really not used is there still a need to keep it?
I don't see a need.
--
a href=http://www.catb.org/~esr/;Eric S. Raymond/a
Mark de Wever schrieb:
Recently there was a discussion on IRC and it seems zipios is no longer
used. If it's really not used is there still a need to keep it?
If we agree to remove it I don't mind to do that job.
Regards,
Mark de Wever aka Mordante/SkeletonCrew
Alink [EMAIL PROTECTED]:
Finally, IMHO this bug reveals a flaw in the design of this _main.cfg :
exploring files and directories differently if we have or not a _main.cfg.
This seems like a non-standard files behavior for me and not very KISS.
Think of Python packages. It's where I more or
On Sun, Mar 18, 2007 at 10:19:42PM +0100, Mark de Wever wrote:
On Wed, Mar 14, 2007 at 12:02:59AM +0100, Mark de Wever wrote:
On Fri, Mar 09, 2007 at 09:01:07PM +0100, Mark de Wever wrote:
I like the idea of configuring how the message is shown, if the dialogs
are too intrusive it's easy
On Thu, May 24, 2007 at 12:59:40PM +0200, David wrote:
Using Boost just for the filesystem would be a nuke, but if we subsequently
encourage developers to use more parts of it in other areas of the code this
doesn't hold anymore. :-)
The parsing code was rewritten by silene in 2005; he was
On Thu, May 24, 2007 at 16:56:08 -0400,
Eric S. Raymond [EMAIL PROTECTED] wrote:
1. We implement #include, just as in the C preprocessor and
for consistency with the existing C=like #ifdef/#else/#endif.
Are you going to fix up including directories some way at the same time?
This would
On Thu, May 24, 2007 at 04:56:08PM -0400, Eric S. Raymond wrote:
I enjoy special-purpose languages and language-like markups. I have a
great deal of experience at designing, implementing, and evaluating
such things. Accordingly, there's a a lot of stuff about design
principles and pragmatics
Bruno Wolff III [EMAIL PROTECTED]:
Are you going to fix up including directories some way at the same time?
This would probably be an opportune time to make changes in that regard,
since all of the includes will be being changed.
Only if it's a change that can be made nechanically by wmllint.
[EMAIL PROTECTED] [EMAIL PROTECTED]:
The problem i see with #include is it is less powerful that our current
system.
With current system we can include any file we want in a middle of a line,
which might not be possible with #include.
mapdata={foo.map} is only the most usual case, but there
On Thu, May 24, 2007 at 06:58:34PM -0400, Eric S. Raymond wrote:
[EMAIL PROTECTED] [EMAIL PROTECTED]:
The problem i see with #include is it is less powerful that our current
system.
With current system we can include any file we want in a middle of a line,
which might not be possible
Indeed I support the basic idea of differentiate file and macro. As a coder,
I also like the #include but as it was said you will lose power.
It's possible. But it's also possible that file inclusions in mid-line
are something we shouldn't be doing, or can be more cleanly handled in
a
21 matches
Mail list logo
