Joerg say many times that he is not in interest to make OWB as complete web-browser. It was just our hope that he will, but as he say, the main decision for the work was "have something more or less usable, while there is not FF". Still, there is no usable FF, but OWB as it can be used up to these times. But will be good if someone brave enough will get the flagship and add more features to it.

@alfkil
Quote:
I think so (can't check for now, but i think its default?). Maybe you can do it as Salas00 suggested and it will solve the problem ? Anyway, maybe better skip it for now, there is for sure much more interesting/important things which need to add for debugger :)

@Mrodfr

Quote:

"Or with the latest beta version (53.13)."

ps. can you please write one time "?", but not "??????" ?:) Because for such questions only answers like "because !!!!!!" can be :)

@Elwood

Hm.. My problem happens exactly when copy from (not to) usb stick, and not many files of different size, but one file of big size (problems start to happens after coping of 300-400mb of the same file). Small files copies to/from fine.

@Elwood

Can you try please to copy any file about 500mb of size from USB to hdd ? (some ISO will be good). I describe the bug on the page 3, but dunno was it fixed or not. While you check it, maybe you can also try to reproduce that bug as well ?

@alfkil
Tested new version:)

New step over disassemble are cool. Now i can step not only through C lines, but also over assembler instructions, what is pretty handy, because developer can understand on what moment exactly registers was changes, and what instruction cause it.

Also now i can load any binary (even without debug information), but BP window show nothing in that case. But still, there (in any binary) "_start" and few other fucntions are present, and maybe it possible somehow to show it as well ? I mean make possibility to works with binaryes which even not have debug information. Of course it will be suck, and you cant debug everything in "good way", but still, developer can try to do steps and breakpoints from the begining, and step-by-step found bug even without debug information.

For example, when i load Filer binary (without debug information) to GDB, it says:

(no debugging symbols found)

(gdb)

But still you can do for example

(gdb) disass _start
Dump of assembler code for function _start:
<xxxxx> xxxxxxxxx
<xxxxx> xxxxxxxxx

(and at this point , aos4 version of GDB happyly crashes btw :) (i use your latest build) And it also crashes on any binary ! For example try to load to GDB your helloword, and do: "disass main", and you will have crash in the gdb:dump_inst()+9x1bc (section 1 @ 0x541fc), and addr2line point on disasm.c:137. Maybe you can upload your latest GDB source, and i will try to fix it myself (or maybe you can do that ?:) )

Anyway, when it works as should (GDB i mean), that "disass _start" even for binary which not have debug info will show you addresses from which your binary are loaded in the memory, and you can understand already in which memory areas binary are placed, and you can try to hexdump something, you can set breakpoints on some addresses and so on. If it possible to add (later, for todo list, maybe:) ), then it will be nice too (imho). Maybe even GDB code can help us (we can just rip off some pieces of code from).

Also i found few bugs :) :

1. hex-viewer window still with unbounded text (i think you just not change it for now, so not "bug", just something to fix later, and all in all not so important for now)

2. select file "db101", BP at main(), start, give DSI in the db101:strip_for_tabs()+0x60 (section 1 @ 0x2828). addr2line says: gui.c:146

3. still BP window are block other ones, and and give you DSI if you press on main window buttons when BP window are active. How to reproduce:
-- select file "helloword".
-- set break at "hello", select
-- start
-- spawn set break window again
-- press on the "step" in the main window while that BP window are active.
At this point button "step" in the main window will be pressed, but nothing will works (i.e., like action not have place). But visually button pressed. Then you press on close in the BP window, and have DSI in the insert_line_breakpoints()+0x24 (section 1 @ 0x8a04). addr2line say: breakpoints.c:101

Hope that help :)

@alfkil

No problems , i in high interest personally to have debugger on os4 :) Every update are worth of testing , because you change/add things fast :)

Btw, how you fix your msr-bug problem ? Some workoraund or you found how to do it "right" ? And by the way, are you betatester ? (i mean if you found a bug in elf.library.kmod already, can you report it internally and be in hope that it will be fixed soon, or, you need to annoy someone from beta-test-team to have a looks at this, and report to bug-report-list) ?

@alfkil
Tryed to test it as hard as i can, and found 2 more UI bugs:

1. press select file, but not choice any file, and pressing chancel button or close gadget give DSI.

2. select file (hello word for example), press BP, choice any BP, press "start",then again press BP, and trying to press "step" in main window: window blocked. Then press close in the BP window, and DSI, with stack point on step()+01c (section 1 @ 0x10c4), which show by addr2line on suspend.c file at line 331.

Just for some fanboyz purposes found in the google nice images which can be used as icon for the debuger (while mason not done one:) ):





There is native aos4 icons from these images (64x64):

first one
second one

@alfkil

Cool ! Tested new version. For first have crash, but i think it because you forget to replace new binary over the old one in the root of archive (new one are 406kb, old one in root was 365 or kind). So i run that one from "src" directory and all goes well.

Now windowses non-blocking. That very good ! I open register/variables/disassemble window, and then do "step" in main one, and see changes (not in disassemble window through, but that not big deal for now. But will be nice to see some marker, which will point on current executed instructions set).

Also bugs with DSI at open, freeing of memory and "its not a ppc binary" are gone ! Cool ! But stil there is problem when you trying to load any other ppc binary (which not have debug info i think) in that "stabs_make_function_list()". and still problem with non-proportional fonts. Its still un-bounded :( Maybe there need some more settings for .. Maybe salas00 can give us a good code-example ..

In others, you make really good progress. I already do some debug stuff over it, and understand for now one bug in my programm, which i detect by checking what registers have and where point instruction pointer :)

Now, if you not scare to much, and still have some motivation , and you will not fear by long post, i will write some ideas , which maybe you will found interesting (very possible that not, so just skip it if so :) ):

1. Registers window.

I think we can design it a bit, just for make it a bit "human readable". On ppc-macos, back in times i did for yourself such table:

Quote:

For sure for aos4 its different, but still there is should be any logic (because of all C compilers and the same ways of argument passing). It can be redesigned like: "system heavy" registers at one table/row (like ip/cr/xer/ctr/lr/msr), "user kind" register at other table/row, which can be splitted also on those which are used for arguments usually (when they passed over stack) and so on. That maybe not big deal, but will be pretty user-friendly, because someone can not know how all the registers used on aos4, and will be nasty to understand it just by watching at registers window.

2. Disassemble window

Maybe there will be good to add like in GDB not just offsets, but function name + offset.

I.e. for now it like : 0x7fc7223c (0x0): stwu r1, -32(r1)
but do it like: 0x7fc7223c (function_name+0x0): stwu r1, -32(r1)

That can be also more friendly and understanable. Also as i say before, maybe will be not bad idea add some mark (or highligthing, or any other way) to show what instruction are in execute for now.

And few feature-requester, which of course, you can just put to to-do list, or ingore at all :)), so:

1. Indicate somehow in breakpoint window, where breakpoint was sets. I.e. mark it somehow, and show it all the time somethere.

2. maybe in disassebler window, also make such list as in "hex-viewer" window, but, with list of all used fucntion in the current source. Maybe it will be handy.

3. add interactive mode-window. I.e. when user press "interactive mode" button, he will have some kind of "debugger shell", in which, he can operate by some commands with memory areas/etc. Maybe the same way as for GDB will be good ? (just add all what is necessary in real). Something like:

x/20 0xXXXXXXXX, will dump that and that
d/10 0xXXXXXXXX, will dump that and that

i.e. just like in GDB by logica, but of course commands can be different and more "human-readable", like: hexdump <address> , show bp, show blalbalba, and so on. And by "help" command show all the possible commands.

The window can looks like this:



Maybe it can be nasty (because you will not need to build GUI windowses for all the oprations, but for some you can just use command line as in GDB).

For example by that "interactive window", you can add all of this which already done by gui, + commands for dump any memory/any area, in hex or in disasseble format. Like GDB in other words .. Dunno maybe of course will be better to do everything the same (like only GUI + mouse, and not interactive), but maybe interactive mode will help a too.

All in all, all of this only "maybe" and "if you in interest to add", because debugger already good and usable.

PS. imho you should suggest a bounty on AB, and i will make few news-posts on amiga-related sites, just to fill up bounty a bit, and make your motivation up a bit more. And imho you can also start to upload it ot os4depot as well, because it good and usable already :)

@alfkil
Found two more bugs: Trying to load "a.out" file (from src directory), it loads ok, then pressing on SetBreak, give GR, with stackpoint:
Quote:

The same if i for testing purposes trying to load "Filer" binary. The same loads fine, and pressing on BP button give the same GR.

addr2line on such stack trace point on "stabs.c:103", which are:
Quote:
I think you not check there something on "if not present, then" ? (not exactly there, but early, at moment of loading).

Second one about loading of non-pcc binary. It sasy in the shell that "its not ppc binary", and then crashes (because i think it not exits correctly at this point?)

@alfkil

Now when i do these 2 ugly "fix" to make debuger works fine, i test it more or less normally for now. And should to say: its indeed almost debugger already ! Of course there is still some missing information (like for example, when you press disassemble, you have just disassembled block, but, without references in which fucntion it. I mean (imho), when you press disasseble, will be cool if it will have in head that C source line, of which we have disassembled part.

Also i noticed, than in Hex Viewer, all the data a bit "unbound". It looks like this:



Will be good if it can have "good border canvas" (that will be easy for developers eyes to do brief views).

Also for now noticed that problem with "blocking windowses UI" : for example you set breakpoint, press start, then few steps, then, you press disasseble window, and then, you want to press "step" again, to see, how disasseble data are changes, but you cant. That a bid bad imho.

Also one more minus for "blocking windowses UI", its that for example, usually developers want to have register-info window all the time, and see in realtimve have it changes.

So (only imho of course), you need to redesign it to non-blocking windowses at this point, just to avoid problems in future :)

All in all its nice already, i think i already will use it for some stuff today (and then, can give more feadbacks).

Thanks for :)

@alfkil
Tryed new version:

with elf.library.kmod from quickfix : run, select hello word, and pressing ok five DSI by memguard

with elf.library.kmod from update2(current one) : run, select hellow word, and pressing ok DSI with GR, GR stack trace:
Quote:

addr2line say:
Quote:

And gui.c at line 492
Quote:

If i comment out these strings, and recompile the debuger, and put elf.library.kmod from quickfix: then it runs, i can load the hello word, and set break button are works, and window not locks. Then i press: HexView button, browse it a bit. Close. Then i press Registers window, close, and have GR:
Stack Trace:

Quote:

Then again addr2line (on hex_free_section_list):

Quote:

And hexview.c at line 95 are:
Quote:

commenting out of these strings did the trick (of course memory will not freed, but who cares for testing-purposes).

So, there is 2 bugs for now: arguments checking and free memory in hexviewer.

@alfkil

If i remember right, it was like this:
aos4.1
quick fix update
update1
update2

right ? I trying to use right now elf.library.kmod from the quick fix update for now : the same lockup on the breakpoint window. Maybe for you works that one from update1 ?

ps. Imho, for now you can redesign UI, just because for now its not too late :) because when you will add more and more feaures over "lockup the windowses" UI, it will be harder to rewrite it later.

@alfkil

Changing only elf.library.kmod give you DSI on IPREFS on start, and you need to change IPREFS on the old one too. After that, system itself a bit unstable (i.e. for example pressing in Filer on db101.lha for unpacking, give you DSI), but unpacking from shell are works.

So, i run it, choice hello word. It loads, say few words about some sections, then i press start. Then again choice load hello word, again start. Then i press "x" button. Then load of hello word third time, and press "breakpoint" - and on that stage window are spawns, and everything lockups. Soft reboot are works, and by dumpdebugbuffer i see nothing.

After that i do reboot, trying to load hello word again, but at this moment i just press "breakpoint" after i select file. And it spawn me window, with fucked symbols, which make me think, that changing on old elf.library.kmod not help much. There is how it looks like:



And after it again lockup.

I have many ideas which can be interesting for you, but firstly need somehow to make works what we have already :)

Check PM plz

@jackepc

Checked: while looks easy (sdl + opengl + few small thinks, i.e. nothing so heavy) - still it use shaders. I not trying to build it at all, but i just unpack the source, and found there is directory "shaders" , in which many files, like:

-- Fragment shader for procedural bricks
-- Vertex shader for procedural bricks
-- Fragment shader for environment mapping with an equirectangular 2D texture

and so on. Looks like it heavy based on shaders.

We can only wait then new drivers + gallium/mesa port. Then it will be 100% possible to port.

@joerg
Can you answer please, why you not enable NPAPI by default all the time with every releases ? Because it will allow to afxgroup somehow understand how he can add gnash to it, or to anyone else, who want to make a plugins.

Then, ppls can create "download manager" plugin , "flash" plugin and any other plugins.

Explain please as deep as you can why you cant enable it for now, and what you (we) need to do, to enable it by default for all the time.

@afxgroup

If you in interest, you can follow by that thread on UB which i start today (about all that BliBltRasPort vs P96WritePixelArray stuff). For now the most intersting answer was from Georg:

Quote:

Maybe we indeed loose somethere src_bm ? (if its need it for).

That can explain such "speedup" (like it copy from nothing to memory).

@Fab

Is there any luck that we can motivate you by money (bounty) to make port to aos4 of your version of OWB ? Or maybe somehow else ? Because while Joerg still do fixes for OWB, there will be nothing new in terms of new features from him for OWB (because OWB its only core:) ), and even enabling of NPAPI makes a problem (just do not undestand, why just not enable it at all for all the time?). We all the time say about the same "please enable NPAPI, please any download manager", but looks like my avatar say more about :)

Will be pretty cool if we can somehow motivate you for such work. You know your code better than anyone else, and maybe it will not take for you so many time ..

@AfxGroup
Btw, one more curios: is BltBitMapRastPort() functions should works over P96 fucntions in end ? Ds i understand, it should also call P96WritePixelArray in end (because in end P96 do all the work). Maybe BltBitMapRastPort() use some heavy checking on lock/unlock screens before do P96 stuff, and because of it its so slow ?

And maybe our current lockups because of "we need some more checking when we can lock/unlock" ? (what maybe do BltBitMapRastPort() and because of it , it so slow).

I just trying to understand, how it posible to have such _very big_ difference in thousands times ..

@KimmoK
Quote:
Better say its Yannick (& felllows) version :) Its still has some bugs/problems/misunderstoods, but already usable. Not so CAD related through :)

Still, good, modern and nice CAD programm are must to have. Did unixes have any good opensource CAD programm ?