Menu
▾
▴
befpc-developer — List for BeFPC developer discussion and related offshoots of the project.
You can subscribe to this list here.
| 2003 |
Jan
(11) |
Feb
(11) |
Mar
|
Apr
(11) |
May
(2) |
Jun
(3) |
Jul
(28) |
Aug
(2) |
Sep
|
Oct
(6) |
Nov
|
Dec
(9) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
|
Feb
(1) |
Mar
(7) |
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(3) |
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Olivier C. <oli...@la...> - 2013-05-30 23:23:00
|
Bonjour, On 30/05/2013 08:21, eric.jourde wrote: > Olivier salut !!! tu vas bien ? > > Tu retravailles sur bePascal ???? Oui, à l'occasion. Quelqu'un m'a demandé si il était possible d'accéder aux attributs avec FreePascal/Lazarus. Je me suis aperçu que les fonctions de base étaient là, mais mal déclarées. Cela m'a aussi permis de vérifier la migration automatique vers la nouvelle plateforme sourceforge qui a eu lieu en avril. Olivier > ------------------------------------------------------------------------------ > Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET > Get 100% visibility into your production application - at no cost. > Code-level diagnostics for performance bottlenecks with <2% overhead > Download for free and get started troubleshooting in minutes. > http://p.sf.net/sfu/appdyn_d2d_ap1 > _______________________________________________ > Befpc-developer mailing list > Bef...@li... > https://lists.sourceforge.net/lists/listinfo/befpc-developer |
|
From: eric.jourde <eri...@la...> - 2013-05-30 06:21:35
|
Olivier salut !!! tu vas bien ? Tu retravailles sur bePascal ???? Eric :) |
|
From: Olivier C. <oli...@la...> - 2012-10-12 18:46:38
|
Hi, On 01/10/2012 19:54, Oscar Lesta wrote: >> [cvs2svn] >> Any objections ? > None, except that I would consider moving all the way into Mercurial or Git. > > I'll probably even drop SourceForge usage, except for hosting download > files and mailing lists, and use Bitbucket or GitHub instead (far > easier to work, specially for small or solo projects). > > They are more "in vogue", and may help make it lower the entry bar for > one-time/occasional collaborators. Well, i thought about that too. But, as i am not yet comfortable enough with those tools, i thought it should be enough to start with subversion first. I will probably create a subversion repository this weekend. I don't have a lot of free time right now to start a more ambitious migration plan and it would be at the expense of code anyway. I will probably reconsider the question in a few months though, especially if there is lots of activities ;-). Olivier, Eric : Thank you for yours answers and support . It is nice to hear from you, too ! Olivier |
|
From: Oscar L. <osc...@gm...> - 2012-10-01 17:54:37
|
Hello there, guys! On Fri, Sep 28, 2012 at 7:21 PM, Olivier Coursière <oli...@la...> wrote: > Hi, > > It's been a long time since the last message in this list. I am not sure > if anybody still registered ;-) Not that it matters much, for my lack of work, but I'm still registered :-D > Since then, i have mostly worked on the freepascal side to make sure it > works under Haiku. Now, it is even possible to compile Lazarus if you > install Qt. Awesome! > [cvs2svn] > Any objections ? None, except that I would consider moving all the way into Mercurial or Git. I'll probably even drop SourceForge usage, except for hosting download files and mailing lists, and use Bitbucket or GitHub instead (far easier to work, specially for small or solo projects). They are more "in vogue", and may help make it lower the entry bar for one-time/occasional collaborators. Olivier, Eric: Take care, guys. It is nice to hear from you again! Oscar. |
|
From: eric.jourde <eri...@la...> - 2012-10-01 06:17:57
|
He he ! si si y-a encore des gens ;) Comment vas-tu mon ami !!! que devient tu ! Bon courage pour poublier le BePascal ! moi j'aurais du mal a remettre la main sur une machine opérationnelle ! (les sources je pense que oui; si tu as besoin fait moi signe). Eric -----Message d'origine----- De : Olivier Coursière [mailto:oli...@la...] Envoyé : samedi 29 septembre 2012 00:21 À : befpc-developer Objet : [Befpc-developer] Message in a bottle : proposition to add a subversion repository to the befpc project Hi, It's been a long time since the last message in this list. I am not sure if anybody still registered ;-) Since then, i have mostly worked on the freepascal side to make sure it works under Haiku. Now, it is even possible to compile Lazarus if you install Qt. Last week, someone ask me some questions about pascal programming under Haiku. It reminds me that i have some fixes on my computer to compile bepascal under Haiku. I would like to publish them, but i don't want to invest time to deal with cvs. It would be easier for me to add a subversion repository on our sourceforge project (keeping all the history, cvs2svn seems to work quite well) and publish my fixes there. With a lower barriers for commits on my side, i will probably improve it from time to time. Any objections ? Regards, Olivier ---------------------------------------------------------------------------- -- Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html _______________________________________________ Befpc-developer mailing list Bef...@li... https://lists.sourceforge.net/lists/listinfo/befpc-developer |
|
From: Olivier C. <oli...@la...> - 2012-09-28 22:21:33
|
Hi, It's been a long time since the last message in this list. I am not sure if anybody still registered ;-) Since then, i have mostly worked on the freepascal side to make sure it works under Haiku. Now, it is even possible to compile Lazarus if you install Qt. Last week, someone ask me some questions about pascal programming under Haiku. It reminds me that i have some fixes on my computer to compile bepascal under Haiku. I would like to publish them, but i don't want to invest time to deal with cvs. It would be easier for me to add a subversion repository on our sourceforge project (keeping all the history, cvs2svn seems to work quite well) and publish my fixes there. With a lower barriers for commits on my side, i will probably improve it from time to time. Any objections ? Regards, Olivier |
|
From: <ben...@id...> - 2004-05-21 09:40:32
|
Dear Open Source developer I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate. You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it. With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development. With many thanks for your participation, Benno Luthiger PS: The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/. We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list. _______________________________________________________________________ Benno Luthiger Swiss Federal Institute of Technology Zurich 8092 Zurich Mail: benno.luthiger(at)id.ethz.ch _______________________________________________________________________ |
|
From: Matt E. <me...@in...> - 2004-03-24 09:41:46
|
> we can make one unit per kit (interface kit, application kit...). All
> classes in a kit are in the same unit -> no circular references. To
> keep things separate, we have to use two include files per objet :
> - one for the interface part
> - one for the implementation part.
>
> It is a far from perfect solution (all classes in a kit are allways
> include), but it should work...
This is why Borland did VCL in this way... many people dislike the way all
VCL classes of a sort are mixed in one unit, but this is the simple (tried
and tested) solution in this circumstance!
I was thinking some more this morning on the way to work... One other idea
is Custom classes:
e.g.
You want to include Bitmap.pp in the interface of View,pp, but View.pp uses
Bitmap already... do like Borland, add an extra srtep, the 'BCustomXXX'
class. This is similar to the Abstract class idea, but simpler in execution.
unit CustomBitmap;
interface
uses
... ; //no View.h in this list, uses non circular ref units and other
'CustomXXX' units.
type
BCustomBitmap = class //more or less an interface... add in all non
BView/circular methods
end;
implementation
uses
...; //any units that need to avoid circular refs
....
end.
unit Bitmap;
uses
CustomBitmap, View, ...; //no direct link
type
BBitmap = class(BCustomBitmap)
//implement methods using all previouslu circular referenced classes
such as BView
end;
implementation
....
end.
unit View;
uses
CustomBitmap, ...; //no direct link
type
BView= class
//implement methods using BBitmap using BCustomBitmap instead,
internally typecasting to BBitmap where needed
end;
implementation
uses
Bitmap, ...;
....
end.
This is the trick some classes in the VCL use anyway. This method uses more
layering to achieve the same goal as the interface version without messy
abstract classes. You would implement 50% - 80% of the class in the custom
version and only the bits that cause circular references in the concrete
class. The Custom class would be used as a param alone, never as an
instance. This would suit Pascal more than the sometimes messy code you end
up with if interfaces go wrong...
Matt
|
|
From: Olivier <oli...@la...> - 2004-03-23 22:26:02
|
Hi all ! > > First, thanks for the suggested solutions! > > No problem ;-) I like to actually do something for BePascal every now > and > again! > > > About the interfaces-based one: > > Yup, thought about that, but: > > > > - Sadly, the last working of FPC for BeOS (and last _compilable_ > > one) is > 1.0.8-pre, and doesn't supports interfaces. In fact, there is 1.0.10a since one week ;-) (Carl has done this last week). But it doesn't change anything about the current problem. Only a minor update (more here : http:// www.freepascal.org/down-beos.html). > > Current tree won't compile again unless a significant amount of > > work is > done in the BeOS RTL. (Olivier, any news there?) > > You'd need a 1.1 branch. I thought that had been achieved... sorry my > mistake. I have done some work on this during last months. I have a RTL that compile, but still some bugs that prevent making a usable 1.9 compiler (the compiler can't compile itself yet). I hope some progress in the next weeks. Currently, i have a memory allocation problem... About avoiding circular references, interface should be the answer if we have a 1.9 compiler. I don't know yet how to do this (i have to think about this before contributing my ideas...) There is also another workaround to the circular reference problem (just to be complete) : we can make one unit per kit (interface kit, application kit...). All classes in a kit are in the same unit -> no circular references. To keep things separate, we have to use two include files per objet : - one for the interface part - one for the implementation part. It is a far from perfect solution (all classes in a kit are allways include), but it should work... I hope some good news in the next days about a 1.9 compiler for BeOS... Bye Olivier |
|
From: Matt E. <me...@in...> - 2004-03-22 11:52:09
|
> and if you use the pre > Delphi 6 version of interfaces, they are reference counted.... just to clarify... delphi 4 and 5 forced all interfaces to be reference counted and have the mothods _addref and _release plus possibly one other. In Delphi 6 onwards, interfaces do not necessarily require this to be so... All D5 interfaces inherit from 'IUnknown', but iirc Delphi 6 onwards uses 'IInterface' or something, 'IUnknown' is a subclass of 'IInterface' that adds those methods. The original purpose of Interfaces was to simplify COM automation, but people started to use them for general programming. They work well, though there are quirks (be careful with ref counting!!) Matt |
|
From: Matt E. <me...@in...> - 2004-03-22 11:10:40
|
> Hello Matt!
>
> First, thanks for the suggested solutions!
No problem ;-) I like to actually do something for BePascal every now and
again!
> About the interfaces-based one:
> Yup, thought about that, but:
>
> - Sadly, the last working of FPC for BeOS (and last _compilable_ one) is
1.0.8-pre, and doesn't supports interfaces.
> Current tree won't compile again unless a significant amount of work is
done in the BeOS RTL. (Olivier, any news there?)
You'd need a 1.1 branch. I thought that had been achieved... sorry my
mistake.
> - There's no BeOS tool/lib to generate GUIDs/UUIDs. (no big deal, I should
clean-up my BeOS implementation of that one so we can use it).
I't just a 64bit number expressed in a delimited form. As they are not used
in BeOS at all, you could just hard code them to be certain values that you
know are unique. FPC may net be as dependent on GUID's too, I just know
Delphi (5) has a real problem if you don't include them.
> - I'll have to actually *learn* about interfaces! ;-P
Interfaces are just codeless classes. Innterfacing an object forces to to
implement the given interface. Any class that implements the interface can
be held in a var declared as that interface type and if you use the pre
Delphi 6 version of interfaces, they are reference counted.... That is to
say, when you set the instance to 'nil' it removes a reference to the
instance from that instances reference counting mechanism. When the last
reference is set to nil, the object instance is destroyed automatically.
One way to implement the whole of the BeAPI in Pascal, and remove all
circular references, would be to use interfaces exclusively and then make
all implementations private and included in the interface setciton alone.
You'd then have a 'newXXXXX' routine for each interface externally, and all
implementation would be private and would therefore stop all circular refs.
This is (logically, not factually) how C++ and C present their code... the
header file is the interface and does not need the C/CPP file to compile, as
long as the implementation is avalable through Object files or libraries.
You simply can't do this in Pascal... and Borland ended up using a bit of a
hack to get it working in Delphi by using packages.
> Still, I agree, seems to be the best long-term solution.
>
> About the abstract-classes based one:
>
> Mmm, haven't thought about them! (shame on me!).
> So, we're stuck with this one unless we get a working FPC > 1.9.0 ?
One thing you could do is create FPC style abstract classes. IIRC FPC has a
keyword that allows you to define a class but in the implementation you just
put this keyword in the empty methods. I forget what it is. 'raise' is an
alternative (EAbstractError.... Then put an {$IFDEF} round the class name
and an {$else} clause like so:
{$IFNDEF USEINTERFACES}
BButtonIntf = class(....)
{$ELSE USEINTERFACES}
BButtonIntf = interface(....) ['a guid']
{$ENDIF USEINTERFACES}
.....
end;
This then allows a simple switch at compile time. Internally you always then
need to have an ifdef whenever you free the object instance:
{$IFNDEF USEINTERFACES}
Button.Free;
{$ELSE USEINTERFACES}
Button := nil;
{$ENDIF USEINTERFACES}
But then you end up with a switchable system which allows older compilers to
be used. If you keep the class/interface name the same, there is almost no
work in the changeover, bar this.
> ===
> I include Matt's reply fully, as it didn't got to the mail list, sorry if
it gets duplicated.
> ===
Oops, my fault... I forget this list always replies to sender rather than
list... Odd... the Syllable list replies to list not sender anf that's on
SourceForge too...
Matt
|
|
From: BiPolar <Bi...@So...> - 2004-03-20 22:11:48
|
Hello Matt! First, thanks for the suggested solutions! About the interfaces-based one: Yup, thought about that, but: - Sadly, the last working of FPC for BeOS (and last _compilable_ one) is 1.0.8-pre, and doesn't supports interfaces. Current tree won't compile again unless a significant amount of work is done in the BeOS RTL. (Olivier, any news there?) - There's no BeOS tool/lib to generate GUIDs/UUIDs. (no big deal, I should clean-up my BeOS implementation of that one so we can use it). - I'll have to actually *learn* about interfaces! ;-P Still, I agree, seems to be the best long-term solution. About the abstract-classes based one: Mmm, haven't thought about them! (shame on me!). So, we're stuck with this one unless we get a working FPC > 1.9.0 ? Thanks again Matt. Oscar. === I include Matt's reply fully, as it didn't got to the mail list, sorry if it gets duplicated. === Matt Emson wrote: > > Please, if someone has an idea, _this_ is the time to speak! :-) > > 1) Interfaces > > IBitmap = interface [SOME-GUID-BECAUSE-OTHERWISE-INTERFACES-DONTWORK-RIGHT] > ... > end; > > BBitmap = class(BInterfacedObject, IBitmap) //you'd need to alter the base > class to be interfaced. I used BInterfacedObject as an example > .... > end; > > IBitmap gors in a unit BitmapIntf, Bitmap goes in a unit Bitmap... Problem > solved. Internally you then use interfaces to instances. This will remove > circular references. > > 2) Abstract interface classes (for FPC lacking interfaces..) > > in 'AbsBitmap' > > AbsBitmap = class(WhateverAncestor) > ....define all memebers, but use 'abstract' qualifier.. > end; > > in 'Bitmap' > > BBitmap = class(AbsBitmap) > ... override all abstract methods... > end; > > > Now you're going to ask how you create them, right? Two methods... > > 1) You have a routine that returns a Interface/Abstract class, but in the > implementation it uses the actual class... make this a class function > > e.g. > > IMyClass = interface > procedure X; > end; > > function getMyClassInstance: IMyClass; > > implementation > > uses MyClass; //avoid circular ref > > function getMyClassInstance: IMyClass; > begin > result := TMyClass.Create; > end; > > ///// MyClass unit > > uses MyClassIntf; > > .... > > MyClass = class(TInterfacedObject, IMyClass) > procedure X; > end; > > > or > > AbsMyClass = class > procedure X; virtual; abstract; > class function getMyClassInstance: TObject; virtual; abstract; > end; > > > ///// MyClass unit > > uses MyClassAbs; > > MyClass = class(AbsMyClass) > procedure X; override; > class function getMyClassInstance: TObject; > end; > > ..... > > class function MyClass .getMyClassInstance: TObject; > begin > Result := MyClass.Create; > end; > > > So, this will only be needed to be used *internally* or in places that cause > you problems with circular references. > > You now know why Borland put everything into the same unit ;-) C/C++ get > round all this by ugly #ifdef's and unfortunately that's not possible... > > Other option is to use Private implementations of the classes.. These get > pulled in as include files. I'll leave this one out as I think it would > probably alter your design too much. > > I would use the interface method over the abstract interface method unless > you're using a version of FPC that does not support interfaces yet (or is > buggy..) > > Matt |
|
From: BiPolar <Bi...@So...> - 2004-03-20 12:17:37
|
I *hate* sf.net mailing list (only one where the "reply" button does not work as expected) ------ Forwarded Message: ------ To: "Mika Lindqvist" <li...@pc...> From: "BiPolar" <Bi...@So...> Subject: RE: [Befpc-developer] From the "Head-Scratching" department. Date: Sat, 20 Mar 2004 09:04:21 -0300 ART Mika Lindqvist wrote: > In C++ it would just require forward declaration - of the other class - in > header (interface) of both classes and include of the other header ('using' > in Pascal?) in source (implementation). Type-casting is indeed very ugly > thing and I don't think that should be the ultimate solution. Yep, and that's the problem, in pascal forwarded declarations _must_ be completed inside the same module where they are declared. And because pascal does type comparition by the type's names... we can't put the interface part in a .inc file and include that in two different modules (you get a "redeclared identifier" or similar error). Now I'm seeing these forwarded declarations more and more in Be's Headers, must be because now I fear them :-). Argh... Long life to C-based APIs! :-P Oscar. P.S: [off-topic] Hey Olivier... do you want to send me the sources of your pascal addon for Pe (the one with the improved function popup)? I got write access to Pe's CVS so... I can put it in if you like. |
|
From: BiPolar <Bi...@So...> - 2004-03-20 03:23:47
|
Hello there. Just a few lines to let you know that: I've been trying to find a way to solve our problem with circular references. BBitmap/BView are the leading case, but we'll face the same problem in lot of places (I was looking at the OT LocaleKit, at it seems we'll have this problem there too :-( ). I did some progress, but the workaround feels ugly, and it doesn't "fix" it for good (for example, BBitmap's functions returning BViews won't work as-is). The work around works like this: defining BView = class in Bitmap.pp's interface, using View in the implementation section, and typecasting everywhere with "View.BView()". What I did was: 1.- made a set of simplistic BeObj, Archivable, Handler, View and Bitmap units, replacing the implementation of the problematic methods with debug output only. 2.- made a program that: creates an instance of BBitmap (wich creates an internal BView), calling BBitmap's FindView, assigning the result to a BView variable. Calling methods from what that variable points to seems to be working correctly. That's the progress. But the work around requires explicit typecastings in every place where the Bitmap's BView and View's BView collide. This is ugly. And sad, because I can't find any other way to make it work. The major problem with this (besides the need to type more) it's that it requiers that you "know" the implementation of the class you are using. Another one, a derived class of BBitmap will also require to know about this issue, and typecast everywhere (*this* is terrible, no?). Doesn't feels scalable. Doing it in the "other direction" (View.pp doing the typecasts of BBitmaps) doesn't seems to be any better. Please, if someone has an idea, _this_ is the time to speak! :-) The only other way I can think of is... <heretic mode> Not following the BeAPI so closely. </heretic mode> This also has its issues, as forcing us to actually create (parts of) an API by ourselves. There are things that I think we could (and should, IMO) change in our wrapper's version of the BeAPI [*], but changing the BBitmap/BView part is not, in anyway, "a minor change" and should be thought carefully. The thing is... if there's no _usable/scalable_ way of solving this problem we may be forced to not follow the BeAPI, at least not there. So, I repeat, if you have an idea, shout. Otherwise, start to thinking in how would you like the new BePascal API to be. :-) [*] for example: dropping the usage of PChar's strings and using just "strings" (this can be done easily, and simplifies the overall class/function usage). Oh well... Oscar. |
|
From: BiPolar <Bi...@So...> - 2004-02-27 03:06:59
|
Hello guys, Sorry for not doing any work lately. I hope I can finally focus on BePascal from now on... Anyway, here's the new version of my Pe extension. Hope you like it. http://befpc.sourceforge.net/files/BeBookExtension-v0.3.zip Later. Oscar. |
|
From: BiPolar <Bi...@So...> - 2003-12-20 03:19:28
|
Hello there. As I did several, but small, changes to many files on our CVS rep... I just wanted to give a list of what I did. In case I broke something, now you'll know where to look at :-) ------------------------------------------------------- /bepascal/pas/src/be/support * DataIO - TNames -> BNames. * SupportDefs - Cardinal -> Longword, other minor changes. * BString - TNames -> BNames. * Flattenable - Tabs -> spaces. /bepascal/pas/src/be/storage * Alias - fixed compiler version ifdefs. + Entry - Added entry_ref. * FilePanel - Chages to match newer Entry.pp + FindDirectory - initial commit. + Mime - initial commit. * Path - Chages to match newer Entry.pp * SupportDefs - Minor changes. * Volume - Minor changes. * VolumeRoster - Minor changes. /bepascal/pas/src/be/app * AppDefs - Modified to use the := operator. * Application - entry_ref and app_info changes. * Roster - EntryRef -> entry_ref. /bepascal/pas/src/be/bepas_kernel + BeObj - Added := operator (Allows: Longword := 'ABCD') * fdblib - trans() -> := operator /bepascal/test/ + OpTest.pas - simple test for the := operator on BeObj. ------------------------------------------------------- Later, Oscar. PS: BTW, I just noticed another massive commit (from oco, I guess), so... if it's broken... it's not my fault! (tm) :-PP |
|
From: Mika L. <li...@pc...> - 2003-12-11 08:28:53
|
> -----Original Message----- > From: bef...@li...=20 > [mailto:bef...@li...] On=20 > Behalf Of BiPolar > Sent: Thursday, December 11, 2003 5:55 AM > To: bef...@li... > Cc: Mika Lindqvist > Subject: Re: [Befpc-developer] Christmas silence? >=20 >=20 > (In case this message was already replied... well, I'm=20 > offline most of=20 > the time so... get used to it :-P) I'm pretty much offline too, because I'm trying to learn Korean and = Japanese for my other projects. >=20 > 4 weeks only! :-P that's because you don't read the befpc-discussion=20 > list :-) Maybe because my ISP is in the e-mail black list and most US-based = servers will block all access. No wonder why I boycott all US-based stuff. > Seriously now... >=20 > We are a little bit too un-organized, true, but well... it doesn't=20 > bothers me too much :-) It doesn't bother me much either, but I'm kinda used to the fact that = when I join a project there happens a lot in the beginning and then comes the silence. With this project the "a lot happens" was just 2 hour marathon = to get about 200 warnings to disappear and that was a good thing for the = sake of future of the project. > I think that we should have, at least, a .txt in the CVS=20 > stating who is=20 > doing what, so we don't duplicate work (as Eric and I did a couple of=20 > times). Or maybe on the www site as I have access to a www browser more often = than to a cvs client. > > I'm still willing to help with the C/C++ part and working on the > > background > > with Garjala trying to freshen his Pascal memories so he could help=20 > > us too. >=20 > Mmm, maybe you can use your C++ expertise to bug-fix my=20 > BAlert? Please?=20 > ;-) I can look at it atleast... When I'm at my BeOS machine. Most errors I = have seen so far have been dangling or missing hooks, so with Be Book and = couple of spare minutes/hours, I might get atleast a little clue what might be wrong. >=20 > Later, >=20 > Oscar. >=20 > PS. I CC this just in case Mika still has problems with the mailing=20 > list. >=20 |
|
From: BiPolar <Bi...@So...> - 2003-12-11 04:02:32
|
Matt Emson wrote: > > I will need your help with this one: > > > > BAlert.Go hangs the app after you click on any button of the alert, > > and > > the asynchronous version (.Go(nil), for example) just crashes the > > app. > > I had this issue with the original stuff I did IIRC. I've completely > forgotton how I fixed it, but looking at my code might help (if it > still > exists in CVS...) It was either something to do with NULL pointers or > the > fact that the BAlert needs to be created in the thread it is > exectuted in > (not thread safe...) Maybe my brain is fried and this is all rubbish > btw ;-) Well, my brain damage is been already certified so, your rubbish could make sense to me :-P Your code is still in the CVS (and I think it should stay there, both because it's your work and because it can serve as comparison. I don't feel the same about the befpc module dough, it's old, big, kinda useless now and we should kill it ;-). Unfortunatly, both approaches (BeGUI/BePascal) has little in common and I could not find any "Light" there this time :-( About the not thread-safeness (this word exist?)... could be... or not... don't have a clue about that! So... I think I will have to wait for someone else to fix it :-P (Do you want it Monni? :-P) Thanks anyway Matt. Later. Oscar. |
|
From: BiPolar <Bi...@So...> - 2003-12-11 04:02:27
|
(In case this message was already replied... well, I'm offline most of the time so... get used to it :-P) Mika Lindqvist wrote: > I just read the archives (because sf.net didn't like to send me any > mailing > list posts; I had to reset my subscription) and noticed that pretty > much > nothing has happened in about 6 weeks. I know everyone is busy doing > something but I just wanted to know when things starts to happen on > it's own > weight again. 4 weeks only! :-P that's because you don't read the befpc-discussion list :-) I'm a little bit confused about the word "again"... when we did that before? :-D Seriously now... Olivier is working on the RTL of the future FPC 2.x (I can't wait to have default parameters!!!). I did BBitmap, and test it as far as I can. Works and doesn't crash anything, but until BViews can draw... all happens off-screen for now. I also did a couple of more units conversion (in the 'support' dir). Eric has been doing a lot of work on BViews to allow drawing so... soon we'll have that in the CVS too. We are a little bit too un-organized, true, but well... it doesn't bothers me too much :-) (In fact, I kinda like it that way). I think that we should have, at least, a .txt in the CVS stating who is doing what, so we don't duplicate work (as Eric and I did a couple of times). Maybe in /bepascal/docs/Tasks.txt with currently auto-assigned task at top and the next most needed work to be done as in a TODO list? For the rest... you could pick up a header file and "convert it", or make some test cases for alredy made classes. Take your pick. > I'm still willing to help with the C/C++ part and working on the > background > with Garjala trying to freshen his Pascal memories so he could help > us too. Mmm, maybe you can use your C++ expertise to bug-fix my BAlert? Please? ;-) Later, Oscar. PS. I CC this just in case Mika still has problems with the mailing list. |
|
From: BiPolar <Bi...@So...> - 2003-12-09 05:29:52
|
It makes me happy to know that everyone is alive and kicking! :-) Thanks for replying. Matt: I'm glad to read from you again! (in wherever "plane of existence" you may be in). In my previous email I didn't asked directly for your "status" because I had read a post or two that you made on some BeOS related websites (ergo, you were still alive :-P). Eric: I hope your daughter gets better "Real Soon Now" (tm), and I wish that you and your wife can recover the lost sleeping time. Eric & Olivier: nice to know that both of you are out of the flooding zone. Olivier: (about FPC 1.9 RTL) nice to know you're working on it. Let me know if I can help with something, ok? Related to the last one: As we need to "translate" to pascal (at least) parts of the "/headers/ posix" because some types and functions are used by the BeAPI... and seeing the following comment on one of our sources: // For Storage kit // TODO : move these declarations in a different unit (but which one ?). // C++ declarations are in /boot/develop/headers/posix/sys/types.h, // not in SupportDefs.h Shouldn't we put those translated units as part of the BeOS RTL of FPC (extending the existing posix files already there) ? Well folks, that's all for now. Later, Oscar. P.S: Eric, if times/life permits, send me your BView files. Thanks :-) |
|
From: BiPolar <Bi...@So...> - 2003-12-09 05:29:51
|
Hi folks. I will need your help with this one: BAlert.Go hangs the app after you click on any button of the alert, and the asynchronous version (.Go(nil), for example) just crashes the app. (in some point in time... Alert was working ok, but then several changes were made on BWindow/BView, and then this bug shown up again) I wasn't able to find the cause of this bug. All seems to be ok on the pascal side, and I strongly suspect of the .cpp file. I don't fully understand all the implications of C++'s multiple inheritance and so... my C++ code is certainly bogus on that. I guess that the bug resides on the C++ constructor of the BAlert. The BAlert (in the synchronous version), after dismissing it, keeps waiting for the release of a semaphore called "looper_lock". After releasing that one, the app crashes with the following stack crawl: BLooper::_LockComplete(BLooper *, long, long, long, long long): _LockComplete__7BLooperP7BLooperlllx: +0037 ec16f187: * fc4589 movl %eax, -0x00000004(%ebp) w>Attention:sc frame retaddr fd0820bc ec16e0e0 BLooper::_Lock(BLooper *, long, long long) + 0000013c fd082104 ec16f21d BLooper::Lock(void) + 00000029 fd082120 ec16d156 BLooper::~BLooper(void) + 00000126 fd08213c ec9d1882 BPLooper::~BPLooper(void) + 0000004e fd082160 ec9f34da .LFB34 + 00000092 fd08217c ec229214 BWindow::DispatchMessage(BMessage *, BHandler *) + 000005f4 fd0821e0 ec190b8d BAlert::DispatchMessage(BMessage *, BHandler *) + 00000021 fd0821f8 ec9d3abd BPAlert::DispatchMessage(BMessage *, BHandler *) + 00000021 fd082210 ec227e5e BWindow::task_looper(void) + 000003d2 fd08228c ec16fd86 BLooper::_task0_(void *) + 00000036 fd0822a0 ec0851ed thread_start + 00000039 Well, I hope someone of you can (help me to) fix this one. Regards, Oscar. |
|
From: Mika L. <li...@pc...> - 2003-12-09 01:05:33
|
I just read the archives (because sf.net didn't like to send me any = mailing list posts; I had to reset my subscription) and noticed that pretty much nothing has happened in about 6 weeks. I know everyone is busy doing something but I just wanted to know when things starts to happen on it's = own weight again. I'm still willing to help with the C/C++ part and working on the = background with Garjala trying to freshen his Pascal memories so he could help us = too. - Monni - |
|
From: Olivier <oli...@la...> - 2003-12-05 19:57:19
|
Hi all ! > Hello=3F Is everybody still alive, right=3F :-D Yes, still alive ! > Please just reply with a yes. (I heard some bad news about flooding > in > France, and got a little worried). Only in the south of France. We are from center of France and i live in the north... > Well, I hope that the cyber-silence is only due to Real-Life (tm). Partly yes ! And i currently focus on the 1.9 RTL (nothing usable yet). I have seen your message in the fpc mailling list, but no time to answer yet ! Baldur is currently working on a complete implementation of BView (with graphics methods). That's all :-( Regards, Olivier |
|
From: BiPolar <Bi...@So...> - 2003-12-05 08:41:58
|
Hello? Is everybody still alive, right? :-D Please just reply with a yes. (I heard some bad news about flooding in France, and got a little worried). Well, I hope that the cyber-silence is only due to Real-Life (tm). Regards, Oscar. |
|
From: <sc...@ma...> - 2003-10-29 20:14:08
|
moin, moin...=20 Magtt schrieb am 29.10.03 : > No. It's simple. The compiler and its source are GPL, but the RTL is LG= PL. > They did this so that no commercial organization could steal their comp= iler > source and sell a binary only version for loads of money, but any user = can > compile an app with FPC compiler and place it under their own license (= or > the LGPL if they like) and can sell it commercially without the need to= give > the source away. Makes a lot of sense really. Thanks for clearing this up - as you might have realized, English is not my mothertounge and sometimes I getlost on abstract texts. bis denne... scholly |
2 messages has been excluded from this view by a project administrator.
