Talk:Decisions and Work

Page for Discussions about the Decisions, sort into the right region and do not forget to sign your comment

ABIv0 / ABIv1 in AROS

Difficult to decide for me the Diff I send to Charlie was the first option. But now when thinking about I tend more to 2. Option. ALB42 (talk) 11:25, 23 December 2015 (CET)

Some non pascal developers might shoot me for saying it, but ABI-v0 is practically as dead as a horse. No direct development is made to v0 itself anymore, but always in v1 trunk. The new v0 (previous named v0-on-trunk) gets updated in a very slow (read yearly base), although critical fixes do get attention. (this is all not by choice but due to practical circumstances).

I do agree that using either v0 or v1 as default might work confusing, imho more so for v0.

in case it helps, Aros v1 is compatible to classic, current v0 attempts to incorporate as many v1 features/fixes without breaking backwards compatibility to old v0 (e.g. older v0 programs still keep running), and as such is not compatible to classic AmigaOS.

unfortunately v1 api is (still) not stable, so we might run into some issues here and there (as far as i've seen, not very critical ones yet -> mostly API library declarations).

imho, if in the end no support for V1 would be added to FPC, then we are on a dead end with regards to AROS. many fixes have been made that ALB complained about or can't live without for his MUI/LCL implementation, but in worse case scenario it would take a whole year for these fixes to find their way back into v0 (which again imho is not a realistic time frame that is practical to work with, unless someone likes to torture him/herself developing MUI/LCL for/on 68k).

Molly (talk) 12:23, 4 January 2016 (CET)

VarArgs Versions of Functions

Currently I like the lcl[1] way the most, would be even possible to extent it to automatically keep track of strings. (Copy them internally and destroy them when the taglist is destroyed). But for the moment the array of PtrUInt and TAG_() is the cleanest and easiest approach. ALB42 (talk) 11:25, 23 December 2015 (CET)

There is an additional important point: at least "array of const" arguments require Object Pascal (or Delphi) mode. Which means ObjPas unit will be automagically linked to the executable. This inflates executable size, and no way around it, which is a big no-no, especially on classic, but we shouldn't depend on it elsewhere either. Our headers should not depend on Object Pascal mode I think. (This is BTW also the reason why systemvartags exists on Amiga - to avoid forcing the headers into OBJFPC mode.)

Chain-Q (talk) 03:15, 24 December 2015 (CET)

If the reason for not using array of const is to avoid dragging in ObjPas then it is to decide whether we want to avoid this for all platforms or not. If the answer would be yes, then we are on our way, if not then either this inconsistency stays (i would rather avoid that) or another solution would have to be found.

The positive thing about an array of PtrUInt is that it seems easier in usage, although array of const should actually be that (but isn't because the missing LongWord vartype). If not mistaken then the latter part will never be solved because of compatibility reasons (which lowers my personal preferences of using array of const).

For OOP programs i take it there would be no real preference, and ALB's lcl example would perhaps be even more more appropriate. It's a real miss that these varargs parameters can't be type-declared so that a change can be easily made (e.g. simple recompile using other type definition when in OOP mode f.e.).

I've always intended to some day experiment with the c dots declaration (e.g. using intermediate link objects for the unit headers to link against, but i believe that would drag in even more overhead.

In principle and personally i consider this topic to be an affair of dragons (and me not even close of being one of those). I am more than willing to help a hand when the overall source-tree requires changes based on decision made.

Molly (talk) 12:03, 4 January 2016 (CET)

@Chain-Q (i think). Amiga and AROS now uses array of PtrUInt. Is there any objection to change this for MorphOS as well ? I am aware this most probably does not matter for MorphOS, and in case it doesn't then why not make things consistent ? E.g. from previous discussion it was not clear if MorphOS was included for this change. I'm willing (or i can perhaps ask ALB for help) to make the changes in case you don't have time yourself.

19:41, 20 March 2016 (CET)

Systemvartags

Remove systemvartags and move all to the units where the nonvarargs version is. ALB42 (talk) 11:25, 23 December 2015 (CET)

See my remark about Object Pascal mode in the varargs question. The reason systemvartags exists is to avoid forcing most of the headers to ObjFPC mode, and thus inflating the executable size with ObjPas unit. So simply moving "array of const" functions is a no-go. We can use an array of longword though, if I remember correctly.

Chain-Q (talk) 03:21, 24 December 2015 (CET)

see also my remark on opening/closing libs. these topics are entwined on that part as well.

For me it comes down to the decision with regards to array of const vs array of PtrUInt vs OOP for vargargs parameters. (see also my remarks there).

Molly (talk) 12:34, 4 January 2016 (CET)

@ALB: when implementing this, please don't forget about unit AmigaLib. Some of those functions are located in there. I still do not know for sure which functions need to go inside AmigaLib, hence the table i created: Amiga vs MorphOS vs Aros content for that unit seems to differ when looking at individual platform SDK's.

Molly (talk) 23:54, 4 March 2016 (CET)

AmigaLib

I vote for introducing Amigalib to AROS (because the SDK also has it). There should be much more helper functions inside like the SetHook() function. ALB42 (talk) 11:25, 23 December 2015 (CET)

I agree. Chain-Q (talk) 03:51, 24 December 2015 (CET)

i agree as well. One note though (probably for Chain-Q), wasn't that called Asysbox or something on MorphoS ? And if yes, do we perhaps want to avoid/change the name amigalib there ?

Molly (talk) 12:28, 4 January 2016 (CET)

It was originally called ABoxLib, because MorphOS historically called the Amiga compatible stuff "ABox". To avoid possible lawyer bullshit from some circles... But for the sake of compatibility with AROS and classic, I already renamed aboxlib.pas to amigalib.pas for 3.0 and trunk. Chain-Q (talk) 23:45, 9 January 2016 (CET)

Ok, thanks very much for the explanation. amigalib.pas it is then Molly (talk) 20:35, 10 January 2016 (CET)

Issue encountered whilst implementing this unit, see link on decision page. So my question is: do we really need this unit and if not, can we remove existing implementations (Amiga, MorphOS) of this unit ? If we do want it, are the three mentioned functions correct as of what needs to go in that unit (and other function moved to their corresponding library units) ? Molly (talk) 21:52, 13 March 2016 (CET)

DoMethod

I prefer currently the 2. Option looks more clear and more close how you would write a Pascal Method

DoMethod(obj, methodname, [param1, params]) -> obj.methodname(param1, param2);

ALB42 (talk) 11:25, 23 December 2015 (CET)

I have no personal preferences on this matter. The SDK is clear, but interpretation might differ. If using a solution that is not in correspondence with SDK then document it and offer an explanation of why it was chosen to not follow SDK.

However, please do acknowledge the fact that there are methods that requires no parameters at all and offer an overload version that supports this.

For me personally, the most important here is the consistency for all supported platforms.

Molly (talk) 18:24, 23 December 2015 (CET)

DoMethod(obj, methodname, []) -> obj.methodname();

do not need a special version, just call this way. hmm for my understanding he SDK is not clear in this point because it's C and both possibilities would follow it. DoMethod(obj, MethodID, ...) does not tell where the "[" should be ;-). With the Option 2 you can force to give a MethodID, because the Footprint tell you how to do it: DoMethod(Obj: PObject_; MethodID: LongWord; Params: array of PtrUInt). With the footprint for Option 2: DoMethod(Object: PObject_; MethodIDandParams: array of PtrUInt); is a little bit strange. In the End both no big difference just need a decision for all Amiga-likes.

ALB42 (talk) 19:35, 23 December 2015 (CET)

MethodID is part of the varargs, but it must be listed in the declaration, due to how C varargs are parsed in C (they're parsed on the callee side relative to the previous argument, which must be named, for this reason). This is why DoMethodA() only has obj and msg arguments, MethodID is part of the msg argument there. And DoMethod() is only a varargs wrapper to DoMethodA() even in C. The additional problem with the version with the separate methodname argument is that the varargs has to be reassembled before calling the underlying DoMethodA(), because MethodID has to be appended to the start of the list. Also we could just add both versions anyway, but I'm a bit afraid this would cause further confusion.

Chain-Q (talk) 03:44, 24 December 2015 (CET)

OpenLibrary/CloseLibrary

I strongly recommend the 1. Option because thats what the people are used to in Windows/Linux. And it work in many sources. If the Library is not there, the application writer has to check for its existence. maybe we can give there a hand by introducing special functions to check if all Libraries open correctly. Sometimes it's wanted the Library is not there (bsdsocket.library for example) ALB42 (talk) 11:57, 23 December 2015 (CET)

I agree that it could be more convenient to use an already 'proofed' and working method.

However, this [draft] was meant to experiment with other solutions. (this was done before the 'bug' in exitproc was discovered -> it can be changed).

I personally would prefer (too soon, perhaps first make it work ?) a solution that goes beyond FPC current default offered solution(s).

The draft as linked to, offers that possibility, but also can be extended to offer all kinds of user definable manners in which the users want to open libraries. e.g. an extra function UserOpenLibs([INTUITIONNAME, GRAPHICSNAME]), OpenDefaultLibs(); or something similar would be possible.

In the end and imho, the best solution would be to not depend on this kind of behaviour, but instead, make the 'retrieval' of the library base smarter. Whenever a librarybase is nil (and used to call a library function), the library should be added to a list (to keep reference for auto-closing), and the library should be auto-opened. The fastest would :be some kind of property behaviour, that is able to switch the actual 'retrieval' function, so that when a library is already opened that it will not goes through the 'nil' check code again.

For ^^ that to be able to happen, i think the easiest would be if there would be a generic entry/exit just before/after unit initialization/finalization is being called. e.g. JustBeforeInitializationOfUnits(), JustAfterFinalizationOfUnits(). e.g. there should be a possibility to 'panic' and exit in a manner that is OS 'friendly', and waste as less resources as possible.

Of course all the above with the notion that user is always able to open close libraries manually using API calls -> which could cause havoc. For that the library base shall not be user accessible, instead it would be users responsibility to provide a library base if he/she want to do things on own initiative.

The whole purpose of the draft as linked to, was to offer one generic location where libraries are opened closed, so that additions/expansions/improvements only has to be done at one single location. The fact that including a special autoopen unit that opens the libraries automatically, was a demonstration of what would be possible (that includes checking if a library actually exist on disk and act accordingly).

Not all above was thinked through extensively, so feedback (especially on impossibilities/issues) would be appreciated

Molly (talk) 17:35, 23 December 2015 (CET)

for sure the current method does not work, so one could also think about to implement the easy solution then with more time think about a more advanced solution for later use. Because with the current situation I can not continue on anything in Amigs/MorphOS. top open the Library when a Libbase is nil sounds like a good idea, but its not, how to notice that it didn't work? you have no backchannel to the program how used the call (and maybe didn't know its a library call). Of course an exception would help but then we end up with the same costy exceptions as I described before.

The librarybases MUST be accessible to the user, especially intuition, exec and such kind, but also other LibBases have interesting fields to use.

And after all one should remember with LCL/fpgui it still should be possible to write multi platform apps, which should not have some special entrance points, error handlings and so on for our systems.

at last I'm a big fan of KISS, and the simplest solution is the solution 1.

ALB42 (talk) 20:07, 23 December 2015 (CET)

Ok, i agree. First make things work then see for a better solution later on -> we must move forward first and have some unity there.

However, i do have some remarks

Is it really necessary to let an exception to occur when a library failed to open ?

Right now (for MOS/Amiga) there is a system requester. I think that should (or would be a good solution that will) suffice.

You say that intuition should be accessible for the user, but on AmigaOS this is currently not the case (i am not talking about the auto opened 'hidden' base with underscore).

Perhaps i explained myself wrongly. RTL required libraries should not be accessible (directly and writeable) by the user, that is what i meant to say. If the user choses to want to open a library manually, then it is users responsibility to open and close _and_ provide a variable in which the base can be stored. The solution provided on github is meant for auto-opening and closing system required units, but can also offer support functionality for the user if user choose to use them.

There definitely is more code required to make things more clear. The main goal of that code is/was to make a centralized system that can be used. Right now (amiga/MorphOS) there is much code duplication.

My main concern with the libraries is that when using the syscall declarations, it is very hard to change the base address variable as the declarations rely directly on them. This is not a problem since only one library requires a task related base (networking).

Also note that the auto opening of libraries is closely related to the vartags unit. If libraries would have a 'delayed' autoopening (only when a function is actively used) then the vartags unit could stay. Personally i do like having all vartags functions inside one single unit, but the drawback of opening every library kills the usability. If that drawback isn't 'cured' i would opt for moving the vartags function to their respective units again. I would love to hear Chain-Q's view on this libraries related issues (as i have also no idea how that would impact MorphOS, if any).

FWIW: as already explained in pm's i really don't care which solution chosen for any of the mentioned topics on this page, as long as it would be possible to have some consistency. The only subject i have a bit more feelings about is the libraries topic, so i raise my voice here a little ;-)

Molly (talk) 02:17, 4 January 2016 (CET)