Am 24.10.2010 20:20, schrieb Vincent Snijders:
> 2010/10/24 Graeme Geldenhuys :
>> On 24 October 2010 19:50, Florian Klämpfl wrote:
>>>
>>> Everybody gets the replys he deserves :)
>>
>> That's correct. :)
>>
>
> At least you agree on some thing :-)
I wondered too, I expected complaints about mi
2010/10/24 Graeme Geldenhuys :
> On 24 October 2010 19:50, Florian Klämpfl wrote:
>>
>> Everybody gets the replys he deserves :)
>
> That's correct. :)
>
At least you agree on some thing :-)
Vincent
___
fpc-other maillist - fpc-other@lists.freepascal
On 24 October 2010 19:50, Florian Klämpfl wrote:
>
> Everybody gets the replys he deserves :)
That's correct. :)
--
Regards,
- Graeme -
___
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net:8080/fpgui/
__
Am 24.10.2010 19:48, schrieb Graeme Geldenhuys:
> On 24 October 2010 19:43, Florian Klämpfl wrote:
>>
>> Why shows git log only a one liners? I though using git fixes this?
>
> God, now you're being stupid too. 'git log' if you are using the FPC
> git mirror, or 'svn log' if you are using FPC's s
On 24 October 2010 19:43, Florian Klämpfl wrote:
>
> Why shows git log only a one liners? I though using git fixes this?
God, now you're being stupid too. 'git log' if you are using the FPC
git mirror, or 'svn log' if you are using FPC's subversion repository
directly.
--
Regards,
- Graeme -
On 24 October 2010 19:11, Marco van de Voort wrote:
>
> I don't understand what providing quick and dirty patches that
How do you get to 'quick and dirty'? Not every small patch is a hack
or quick or dirty. The same applies for bigger patches. If the author
of the patch simply explains in th
Am 24.10.2010 19:37, schrieb Graeme Geldenhuys:
> Just to 'svn log' or 'git log' and actually look at the history of the
> FPC project and the commit messages of each commit. 99% are one
> liners.
Why shows git log only a one liners? I though using git fixes this?
_
On 24 October 2010 19:09, Florian Klämpfl wrote:
>
> Oh yes, the vcs is to blame for poor commit comment.
Or maybe actually manager YOUR project better, by telling all the
read/write users of your project to give better commit messages.
Nobody can describe a patch very well, and the reason for th
2010/10/23 Adem :
> work, use git to ingrate that fix/feature after every update.
> This way, you will have micro-forked FPC (or Lazarus or whatever) but it is
This works very well indeed. I have +- 15 such feature branches for
Lazarus IDE alone, and it takes all of 1 minute to rebase and merge
th
In our previous episode, Graeme Geldenhuys said:
> > Graeme's last mail where he explains he just wants to drop quick and dirty
> > patches AND IT IS FPC'S CORE TEAM JOB to make head or tails of it,
> > explains the fundamental misconception better than I could do here.
>
> And here I thought that
Am 24.10.2010 19:03, schrieb Graeme Geldenhuys:
> On 22 October 2010 20:20, Marco van de Voort wrote:
>>
>> Graeme's last mail where he explains he just wants to drop quick and dirty
>> patches AND IT IS FPC'S CORE TEAM JOB to make head or tails of it,
>> explains the fundamental misconception bett
On 22 October 2010 20:20, Marco van de Voort wrote:
>
> Graeme's last mail where he explains he just wants to drop quick and dirty
> patches AND IT IS FPC'S CORE TEAM JOB to make head or tails of it,
> explains the fundamental misconception better than I could do here.
And here I thought that is w
On 2010-10-24 13:15, Marco van de Voort wrote:
In our previous episode, Adem said:
But, I must say I am disappointed at the lack of management skills.
You should ask yourself how management skills work in a community where
nobody can force work on sb else.
It takes an infinite amount of patie
In our previous episode, Adem said:
> >>
> >> But, I must say I am disappointed at the lack of management skills.
> > You should ask yourself how management skills work in a community where
> > nobody can force work on sb else.
> >
> It takes an infinite amount of patience.
Yes. Forever, since it
On 2010-10-22 21:20, Marco van de Voort wrote:
In our previous episode, Adem said:
I don't mind the filter; this is life, it happens,
But, I must say I am disappointed at the lack of management skills.
You should ask yourself how management skills work in a community where
nobody can force wor
In our previous episode, Adem said:
> I don't mind the filter; this is life, it happens,
>
> But, I must say I am disappointed at the lack of management skills.
You should ask yourself how management skills work in a community where
nobody can force work on sb else.
Graeme's last mail where he e
In our previous episode, Hans-Peter Diettrich said:
> > To implement a complicated feature, you need to break down the
> > implementation into a lot of patches to make it easy for review.
>
> This is a contradition, IMO. Big changes can not always be broken down
> into smaller steps, when the res
Am 22.10.10 14:00, schrieb Florian Klaempfl:
Am 22.10.2010 13:30, schrieb Helmut Hartl:
Am 22.10.10 13:09, schrieb Graeme Geldenhuys:
Op 2010-10-22 12:43, Adem het geskryf:
This 'list noise' concept must be peculiar to FPC/Lazarus crowd for I
have never seen it come up anywhere else.
+1
-1E3
Op 2010-10-22 12:47, Hans-Peter Diettrich het geskryf:
>
> Regardless of the reasons, a separate git repository would allow for any
> number of additional contributions. My problem still is how to set up
> such a repository, for public use, and how to sync it with the SVN
> trunk. Can your fpc/
Am 22.10.2010 14:20, schrieb Sven Barth:
> Am 22.10.2010 14:11, schrieb Florian Klaempfl:
>> Am 22.10.2010 13:38, schrieb Graeme Geldenhuys:
>>>
>>> God sakes man, this is ridiculous! Look at other successful open source
>>> projects - they don't work like that. If your patch works, that enough.
>>
Am 22.10.2010 14:11, schrieb Florian Klaempfl:
Am 22.10.2010 13:38, schrieb Graeme Geldenhuys:
God sakes man, this is ridiculous! Look at other successful open source
projects - they don't work like that. If your patch works, that enough.
Oh yes, bringing a patch into the linux kernel is just
Op 2010-10-22 13:30, Helmut Hartl het geskryf:
>
> That's the language spoken on other places.
...and I should forward you some of the private messages I received after
discussions in FPC or Lazarus mailing lists. Yes they kept it in private,
but the language used and personal insults will make L
Am 22.10.2010 13:38, schrieb Graeme Geldenhuys:
>
> God sakes man, this is ridiculous! Look at other successful open source
> projects - they don't work like that. If your patch works, that enough.
Oh yes, bringing a patch into the linux kernel is just simple compared
with FPC. Xen, ReiserFS4, An
Graeme Geldenhuys schrieb:
personally, if I wanted to do something major with fpc, I'd not bother
trying to get it integrated to the main branch, I'd spawn my own
project, call it something else, and make it clear that it comes from
It seems more and more people are thinking like that. Th
Jonas Maebe schrieb:
Fixing the the unit reloading logic is quite critical, because it's the
main cause of crashes and other weird errors you sometimes (or
regularly, depending on how many circular dependencies you have and the
kind of changes you make) get when recompiling units without erasi
Adem schrieb:
On 2010-10-20 09:31, Graeme Geldenhuys wrote:
Op 2010-10-20 03:30, Hans-Peter Diettrich het geskryf:
SourceForge has good project management tools, from bug reporting,
mailing lists (though I prefer newsgroups),
I also prefer newsgroups.
I could try to set one up, but INN simp
Op 2010-10-22 13:40, Jonas Maebe het geskryf:
>
> That's fine for simple patches and such patches are normally directly
> committed to FPC. If someone wants to rewrite/restructure half the
> compiler however, then it's not fine, because such a patch can easily
Valid point. But sometimes [in m
Am 22.10.2010 13:30, schrieb Helmut Hartl:
> Am 22.10.10 13:09, schrieb Graeme Geldenhuys:
>> Op 2010-10-22 12:43, Adem het geskryf:
>>> This 'list noise' concept must be peculiar to FPC/Lazarus crowd for I
>>> have never seen it come up anywhere else.
>> +1
> -1E38
>
> http://thread.gmane.org/gma
On 2010-10-22 14:27, Florian Klaempfl wrote:
Anyways, just created a mail filter for you, guess where the mails end :)
I don't mind the filter; this is life, it happens,
But, I must say I am disappointed at the lack of management skills.
___
fpc-other
On 2010-10-22 14:02, Aleksa Todorovic wrote:
2010/10/22 Adem:
Let me answer as someone who wrote several patches, and only one or
two of them were accepted.
I do appreciate you responding to these questions, but I would also like
to hear Florian's comments for his stance (whether he likes it or
On 22 Oct 2010, at 13:38, Graeme Geldenhuys wrote:
This is where I think FPC and Lazarus teams get it all wrong. Not
everybody
wants to "join for life", hold hands and cuddle around the source
code.
Many times I use a tool, find a bug or annoyance, fix it and
contribute
back by supplying
Op 2010-10-22 13:02, Aleksa Todorovic het geskryf:
>> First, how would you prove you're worthy of the task?
>
> Firstly, you need to understand how FPC development works, and to
> accept that. Secondly, you need to show other FPC developers that you
> are willing to work (continuous task) and work
Am 22.10.10 13:09, schrieb Graeme Geldenhuys:
Op 2010-10-22 12:43, Adem het geskryf:
This 'list noise' concept must be peculiar to FPC/Lazarus crowd for I
have never seen it come up anywhere else.
+1
-1E38
http://thread.gmane.org/gmane.comp.version-control.git/57643/focus=57918
That's the la
Am 22.10.2010 12:33, schrieb Adem:
> On 2010-10-22 11:53, Florian Klaempfl wrote:
>> Am 22.10.2010 10:31, schrieb Adem:
>>> Let's suppose that we have agreed that it would be much more fun and
>>> more useful to turn FPC itself into a kind of component/module which
>>> itself is composed of compone
Am 22.10.2010 13:09, schrieb Graeme Geldenhuys:
> Op 2010-10-22 12:43, Adem het geskryf:
>> This 'list noise' concept must be peculiar to FPC/Lazarus crowd for I
>> have never seen it come up anywhere else.
>
> +1
Well, other people call it trolling.
_
Op 2010-10-22 12:43, Adem het geskryf:
> This 'list noise' concept must be peculiar to FPC/Lazarus crowd for I
> have never seen it come up anywhere else.
+1
Regards,
- Graeme -
--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://opensoft.homeip.net:8080/fpgui/
__
2010/10/22 Adem :
> On 2010-10-22 11:53, Florian Klaempfl wrote:
>>
>> Am 22.10.2010 10:31, schrieb Adem:
>>>
>>> Let's suppose that we have agreed that it would be much more fun and
>>> more useful to turn FPC itself into a kind of component/module which
>>> itself is composed of components/module
Op 2010-10-22 12:08, Aleksa Todorovic het geskryf:
>
> On the other hand, you can always make a fork, and have Graeme
> criticize your code in several years ;-)
Hey, that's a cheap shot. Be nice. :)
Regards,
- Graeme -
--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http:
On 2010-10-22 10:35, Florian Klaempfl wrote:
Indeed, you're one of the few example where mailing list noise is not
inversely propotional with the produced code though you didn't fork FPC
yet either ;)
This 'list noise' concept must be peculiar to FPC/Lazarus crowd for I
have never seen it come u
On 2010-10-22 13:33, Adem wrote:
I'd bet you already didn't have a more detailed plan in your head.
This should have been: I'd bet you already *DO* have a more detailed
plan in your head.
___
fpc-other maillist - fpc-other@lists.freepascal.org
http
On 2010-10-22 11:53, Florian Klaempfl wrote:
Am 22.10.2010 10:31, schrieb Adem:
Let's suppose that we have agreed that it would be much more fun and
more useful to turn FPC itself into a kind of component/module which
itself is composed of components/modules so that people can use FPC as
an engi
On 22 October 2010 10:28, Hans-Peter Diettrich wrote:
> Henry Vermaak schrieb:
>
>> Oh wow, so you want to change the parser because it "sounds" nice to you?
>>
>> Seriously, if this work was done more co-operatively with the fpc
>> team, it may have made it. But I think it is too ambitious in th
On Fri, Oct 22, 2010 at 11:33, Hans-Peter Diettrich
wrote:
> Henry Vermaak schrieb:
>
>> To implement a complicated feature, you need to break down the
>> implementation into a lot of patches to make it easy for review.
>
> This is a contradition, IMO. Big changes can not always be broken down int
2010/10/22 Adem :
>
> Fine, lest's look at that: Did you notice the response from the core that
> --to the effect, that is-- the code is 15 years mature and those who are
> familiar with it aren't prepared to see things shifted around.
I'm sure they will be happy to accept changes to very old and
Am 22.10.2010 11:28, schrieb Hans-Peter Diettrich:
> Henry Vermaak schrieb:
>
>> Oh wow, so you want to change the parser because it "sounds" nice to you?
>>
>> Seriously, if this work was done more co-operatively with the fpc
>> team, it may have made it. But I think it is too ambitious in the
>
Am 22.10.2010 11:21, schrieb Hans-Peter Diettrich:
> but most likely I
> won't separate such changes into specific commits, when I come across
> them while working on an different issue.
You should really learn the basics of cooperative software development
before trying to show up as the great so
Henry Vermaak schrieb:
To implement a complicated feature, you need to break down the
implementation into a lot of patches to make it easy for review.
This is a contradition, IMO. Big changes can not always be broken down
into smaller steps, when the result only compiles after a lot of such
Henry Vermaak schrieb:
Oh wow, so you want to change the parser because it "sounds" nice to you?
Seriously, if this work was done more co-operatively with the fpc
team, it may have made it. But I think it is too ambitious in the
first place.
All my projects are ambitious, because I prefer to
Florian Klämpfl schrieb:
1) In the fpc-devel I have read quite a few arguments that FPC is
production quality and no significant changes can be afforded to that code.
While I sympathize with what that implies, it also means that,
structurally, FPC is more or less frozen
This is wrong. If a b
Adem schrieb:
1) In the fpc-devel I have read quite a few arguments that FPC is
production quality and no significant changes can be afforded to that code.
This should have been stated much earlier, before I ever started to
think about refactoring the compiler :-(
While I sympathize with wh
Am 22.10.2010 10:31, schrieb Adem:
> Let's suppose that we have agreed that it would be much more fun and
> more useful to turn FPC itself into a kind of component/module which
> itself is composed of components/modules so that people can use FPC as
> an engine for their projects more directly, whi
On 22 Oct 2010, at 10:31, Adem wrote:
Focus on unit compilation/loading and/or the register allocator?
Of course, you could do that (and by the looks of it, it already is
on your mental roadmap too), but are they really --really-- that
critical?
Fixing the the unit reloading logic is qui
On 2010-10-22 10:04, Florian Klaempfl wrote:
> Am 22.10.2010 03:21, schrieb Adem:
>> And, how exactly do you expect them to be proved?
>
> Features. Examples why it fixes this or that bug. I didn't see a simple
> example why splitting the parser into syntactic and semantic parts gives
> any advant
Am 22.10.2010 09:41, schrieb Florian Klaempfl:
> Am 22.10.2010 09:37, schrieb Graeme Geldenhuys:
>> Op 2010-10-22 09:04, Florian Klaempfl het geskryf:
>>> Other people spent years of their life into getting something working
>>> and now suddenly somebody pops up and thinks he can do better?
>>
>> I
Am 22.10.2010 09:37, schrieb Graeme Geldenhuys:
> Op 2010-10-22 09:04, Florian Klaempfl het geskryf:
>> Other people spent years of their life into getting something working
>> and now suddenly somebody pops up and thinks he can do better?
>
> It's called evolution. Every new generation is suppose
Am 22.10.2010 09:30, schrieb Graeme Geldenhuys:
> Op 2010-10-22 09:12, Florian Klaempfl het geskryf:
>>
>> Don't worry, we know this for years.
>> - "If the FPC team doesn't do what I want I use software XY"
>> - FPC team: "Fine, do so"
>> - "Then I fork FPC"
>> - FPC team: "Fine, do so"
>> - *sile
Just a simple adhesion testimony from a satisfied FPC-user.
I am very glad that FPC WORKS and that it works the way it does!
In particular in combination with the retro-like medieval DOS-IDE!
This combo of FPC with the IDE allow me to use and expand my projects
in a way that I started in 1989 usin
Op 2010-10-22 09:04, Florian Klaempfl het geskryf:
> Other people spent years of their life into getting something working
> and now suddenly somebody pops up and thinks he can do better?
It's called evolution. Every new generation is supposedly producing more
clever people than the generation bef
Op 2010-10-22 09:12, Florian Klaempfl het geskryf:
>
> Don't worry, we know this for years.
> - "If the FPC team doesn't do what I want I use software XY"
> - FPC team: "Fine, do so"
> - "Then I fork FPC"
> - FPC team: "Fine, do so"
> - *silence*
Then I must be the exception to the rule. I didn't
Am 22.10.2010 09:08, schrieb Graeme Geldenhuys:
> Op 2010-10-22 03:41, Travis Siegel het geskryf:
>> personally, if I wanted to do something major with fpc, I'd not bother
>> trying to get it integrated to the main branch, I'd spawn my own
>> project, call it something else, and make it clear t
Am 22.10.2010 03:21, schrieb Adem:
> On 2010-10-22 02:50, Henry Vermaak wrote:
>> 2010/10/21 Adem :
>>> On 2010-10-22 01:23, Henry Vermaak wrote:
>>>
>>> Did you notice the word 'promises'?
>> Somehow you have to prove these "promises".
> And, how exactly do you expect them to be proved?
Features
Op 2010-10-22 03:41, Travis Siegel het geskryf:
> personally, if I wanted to do something major with fpc, I'd not bother
> trying to get it integrated to the main branch, I'd spawn my own
> project, call it something else, and make it clear that it comes from
It seems more and more people ar
I'm probably not the best person to comment here, since I've already
been blasted in the past for telling things like they are, but me
personally, if I wanted to do something major with fpc, I'd not bother
trying to get it integrated to the main branch, I'd spawn my own
project, call it som
On 2010-10-22 02:50, Henry Vermaak wrote:
2010/10/21 Adem:
On 2010-10-22 01:23, Henry Vermaak wrote:
Did you notice the word 'promises'?
Somehow you have to prove these "promises".
And, how exactly do you expect them to be proved? On paper?
Seriously, if this work was done more co-operative
2010/10/21 Adem :
> On 2010-10-22 01:23, Henry Vermaak wrote:
>
> 2010/10/21 Adem :
>
> On 2010-10-21 23:47, Florian Klämpfl wrote:
>
> This is wrong. If a big change promises significant advantages for FPC
> users, it will be done.
>
> The qualifier 'significant' (above and below) is far too subje
On 2010-10-22 01:23, Henry Vermaak wrote:
2010/10/21 Adem:
On 2010-10-21 23:47, Florian Klämpfl wrote:
This is wrong. If a big change promises significant advantages for FPC
users, it will be done.
The qualifier 'significant' (above and below) is far too subjective
sometimes to even have a hop
2010/10/21 Adem :
> On 2010-10-21 23:47, Florian Klämpfl wrote:
>
> This is wrong. If a big change promises significant advantages for FPC
> users, it will be done.
>
> The qualifier 'significant' (above and below) is far too subjective
> sometimes to even have a hope of arriving at a common ground
On 2010-10-21 23:47, Florian Klämpfl wrote:
This is wrong. If a big change promises significant advantages for FPC
users, it will be done.
The qualifier 'significant' (above and below) is far too subjective
sometimes to even have a hope of arriving at a common ground.
But, I'll take my chaces
On 2010-10-20 09:31, Graeme Geldenhuys wrote:
Op 2010-10-20 03:30, Hans-Peter Diettrich het geskryf:
SourceForge has good project management tools, from bug reporting,
mailing lists (though I prefer newsgroups),
I also prefer newsgroups.
I could try to set one up, but INN simply scares me.
E
Am 21.10.2010 22:13, schrieb Adem:
> I don't have the top post (
> http://lists.freepascal.org/lists/FPC-other/2010-October/000468.html )
> in this thread to comment on in a more conversation fashion, as a result
> I reverting to bulleted listing of my views on the subject.
>
> 1) In the fpc-devel
I don't have the top post (
http://lists.freepascal.org/lists/FPC-other/2010-October/000468.html )
in this thread to comment on in a more conversation fashion, as a result
I reverting to bulleted listing of my views on the subject.
1) In the fpc-devel I have read quite a few arguments that FPC
Op 2010-10-20 03:30, Hans-Peter Diettrich het geskryf:
> possibly a dedicated mailing list, chat room... Graeme, you seem to be
> the git expert, what would you suggest for the repository topic?
SourceForge has good project management tools, from bug reporting, mailing
lists (though I prefer news
There seems to exist some interest in FPC modifications that are
incompatible with the official FPC code (SVN trunk). If so, we should
find means to open one or more public alternative repositories, and
possibly a dedicated mailing list, chat room... Graeme, you seem to be
the git expert, what
73 matches
Mail list logo
