Wiki improvements

Forum for discussion about the documentation project.
Juergen Kuehlwein
Posts: 162
Joined: Mar 07, 2018 13:59
Location: Germany

Re: Wiki improvements

Postby Juergen Kuehlwein » Jun 10, 2019 10:32

Don´t worry Jeff, it´s just thinking about and discussing concepts. Feel free to move this topic and corresponding posts elsewhere, because it´s not really about wiki improvments

Maybe a cookie (var/fix length array flag) could be stored just before the descriptor structure:

- a "hidden" Integer at address = @Cptr(Integer Ptr, @descriptor)[-1]


This is better than my proposal."Old" code (e.g. a dll) would definitely get into trouble with my "new" descriptor, even if the size didn´t change, because it would still interpret the bitmask as a value and therefore read wrong values.

Taking a closer look at the RTL i can see that the descriptor isn´t saved to disk when saving an array, it´s only the array´s data. So the only remaining case i can think of when "new" code is confronted with an "old" descriptor, would be a call (an "old" dll calls an exported sub/function of a "new" executable, passing an array) from "old" code (do you agree, or did i miss something?). This could be a problem, because how can we be sure, that the integer before the descriptor is valid memory? And if it is valid, how can we decide, if it´s our hidden flag or something else (random)?

The other way round ("old" code receiving a "new" descriptor) it should work quite well, because the "old" code gets exactly, what it expects. It doesn´t know and it doesn´t care about the hidden flag.


JK
fxm
Posts: 9010
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Wiki improvements

Postby fxm » Jun 10, 2019 17:55

coderJeff wrote:Fix for #893 Typo in error message 148 is now merged in to fbc/master.

Thank you.
dodicat
Posts: 5814
Joined: Jan 10, 2006 20:30
Location: Scotland

Re: Wiki improvements

Postby dodicat » Jun 10, 2019 18:58

Maybe the Wiki is improved with the suffix change, but fb hasn't.
Large chunks of forum code no longer compile.
Why was that particular change made anyway?
fxm
Posts: 9010
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Wiki improvements

Postby fxm » Jun 10, 2019 20:26

dodicat wrote:Maybe the Wiki is improved with the suffix change, but fb hasn't.
Large chunks of forum code no longer compile.
Why was that particular change made anyway?

This is one of the last fixes of dkl in the rev 1.06.0:
[fixed] (rev 1.06.0)
- #832: Fix bug allowing QB style suffixes on all keywords, regardless of -lang
fxm
Posts: 9010
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Wiki improvements

Postby fxm » Jun 13, 2019 15:56

fxm wrote:
dodicat wrote:Maybe the Wiki is improved with the suffix change, but fb hasn't.
Large chunks of forum code no longer compile.
Why was that particular change made anyway?

This is one of the last fixes of dkl in the rev 1.06.0:
[fixed] (rev 1.06.0)
- #832: Fix bug allowing QB style suffixes on all keywords, regardless of -lang

@dkl,
Could you answer dodicat's questioning?
coderJeff
Site Admin
Posts: 2901
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: Wiki improvements

Postby coderJeff » Jun 16, 2019 18:43

I think the main point of bug report #832 was that fbc should error on suffixes used where they shouldn't be, like on keywords. However, this is still allowed by fbc (even with the "fix"):

Code: Select all

#lang "fblite"
if$ 1 then%
   print!
end if

For other use of suffixes in "-lang fb", like on variables, a warning with "-w pedantic" would probably be a better approach. If the usage doesn't actually break anything, it can be allowed, but I like the option of a pedantic warning that I can use fbc to help clean up source code if I want to remove suffixes.
fxm
Posts: 9010
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Wiki improvements

Postby fxm » Jul 04, 2019 19:30

@coderJeff,
about adding a new anchor (link to a location on the same page).

I added this note in /wiki/FBWikiFormatting documentation page:
Note about adding a new anchor:
- Don't pretest the new anchor link through the "Preview" mode, otherwise that cancels all changes in progress done with "Edit" (check only the added text associated with the new anchor).
- But execute "Store" to first save the adding in progress and quit the "Edit" mode, and only then, we can test in "operational" the functioning of the new link.

Because I had a good time before understanding this behavior.

Return to “Documentation”

Who is online

Users browsing this forum: Google [Bot] and 1 guest