@ZeroG

Quote:

Yes, fat95 was reported to work, but don't ask me how.. i never used it. AFAIK you have to do proper mountlists, but as said, i don't know how they have to look like as i never used fat95.

And regarding your crossdos problems: I can't reproduce them here. I just copied hundrets of megabytes to my OCZ 4GB USB stick and from there back to RAM:, then checked the md5 sums of the files. Not a single error.

@ZeroG

Not that i know of, sorry.

@Chris

Quote:


Just to let you know, i spent this weekend on this (and some other) issues to get finally (and successfully) rid of them ;)

@interrogative

Are you saying that your system is crashing with a DSI only by opening e.g. the RAM Disk drawer?

And that is happening with a very clean OS4.1 install? No other 3rd party stuff installed?

Thats almost impossible. If there were any such serious bugs, the installation already would have crashed as it is using the very same components which are then installed onto harddisk. So please verify that everything is OK if you boot from the 4.1 CD, i.e. no crashes.

If so, then you definitely don't have a "clean" OS4.1 install on your harddisk.

If you experience crashes already on the from-CD-booted Workbench, then there might really be a problem..

In any case it might be worth to check the usual suspects anyway: battery, memory, cooling of CPU and graphicscard.

@my_pc_is_amiga

Quote:

Can't reproduce that neither on SAM nor on my A1.

Quote:

Crashlogs are fine, nifty and usefull.. but you have to provide a good description of how such a crash can be reproduced, ie. a step-by-step guide. We don't have any crystal balls handy nor the time to try a thousand of possibilities how a crash somewhere in the system might happen.

@TSK

Quote:

That doesn't mean it can't be bad again. My first A1 battery also lasted almost 4 years, but the second was dead after 2 months again, the third is now going for more than half a year...

Just check the current of the battery to be sure. It isn't much work but it rules out one possible problem.

Quote:

Oh and because you checked your car already many years ago it can't be broken *today* or what?

Come on.. you have the problems *now*, so you have to make the checks *now*.

Quote:

That doesn't mean that it can't get hot! Man, exactly the opposite: without a fan it can get even hotter... maybe you should place a fan over it just to be sure.


.. but .. wait.. i tried to help you with an OS4.1 crash and told you 3 common problems which may perfectly be the reason for the crash AND i told you how these possible reasons could be ruled out.. but you don't seem to actually want help because things like "i checked my memory years ago and it was fine" or "my 1st battery lasted for years, so the new one can't be worse" or "nah, my graphics card is passively cooled, so it simply can not get hot" is just .. well.... utterly bullshit!

sorry to say so, but this are the facts: if you ask for help, accept the offered help and do your parts on finding the reason. If you aren't willing to do a simple current-check of your battery, then stop complaining about problems or crashs right now! Simple as that..

P.S: Yes, i am pissed..

edit: double post

@TSK

Quote:

If rtg.library would have a "nasty bug" this would have been spotted long before the actual release of OS4.1. Noone else is spotting this, so its very likely a problem only on your side.

You should check the usual suspects in case of random crashes:

- If on A1, check your battery. The battery *has* to deliver 3V. Anything lower than that can lead to unpredictable problems. Of course, the lower the current the more problematic it is.

- Check your memory. More than often faulty memory caused random crashes for many people. There is a memtester on os4depot which you should run after booting without startup-sequence for a long time (e.g. over night). A quick test for heavily broken memory would be to just fill up the RAM disk. E.g. copy a 100MB file into RAM Disk over and over again until its filled up or crashed. But as said, this only happens for heavy memory errors.

- Last not least: Make sure your graphics cards cooling works and won't let become the gfx chip too hot. OS4.1 with compositing makes much more use of the gfx card than older versions, so with an improper cooling your gfx card may easily overheat..

@Chris

Ok, thanks. Already fixed it. AmiDock will now send APPLIBMT_Unhide before APPLIBMT_ToFront on left-click on an AppDocky (or also if the AppDockies hotkey is used) if the application is hidden.

But i don't know when/if there will be an update with that AmiDock version included, so you should keep it "unfixed" until then.

@Chris

Yes, please "fix" Wet to behave exactly like the autodocs suggest and send me that version .. i hadn't yet had the time to look at it, but i promise i will during this week or so (after i got Wet from you to be able to reproduce and test).

Thanks.

@Hitman

Quote:

Officially supported are:

RTL8029 (10Mbit)
RTL8139 (100Mbit)
RTL8169 (1000Mbit, but due to other constraints not really fast)

Best bet is the 8139. But beware: everything but 8029 needs fully working DMA. So especially for a Classic only 8029 is supported (or use the 3rd party drivers).

On A1 you can also use eth3com with compatible PCI cards (sorry, don't remember the exact 3com chip anymore.. some 905 or so).

And on SAM you have the built-in 100Mbit ethernet of the 440 PowerPC.

@Hans

I remember saying that already back when the wxwidget-aos project was brought up on aw.net:

Coincidently i started to look at wxWidgets myself just some days before that thread and it took me only some hours to update the wxwidget-aos stuff to the latest official wxWidgets.. thats really no big deal if you know how to use "diff" or if you cheat like me with using WinMerge on Winblows

I wanted to contribute that stuff but i never found the time to clean it up and then i also just forgot about it..

Well, it's outdated again in the meantime probably so it wouldn't be of great use anyway, but if you want i will note it down to my todo-list and have a look again on that code, update it to the latest wxWidgets and send it to you. But be warned: it will take some time until i can spend some time on it again. AND: I probably won't contribute to the project itself anything.. at least not in the foreseeable future (i.e. implementing the AOS backend).

@ all
In general to wxWidgets: A "port" of wxWidgets isn't just a matter of getting the thing to compile.. but it isn't as hard as one might think either.. the porter has first to get the very basic stuff compiling and working (wxWidgets-aos and wxBase are good starting points), then implement one widget (and maybe one or another classe) after each other to slowly build the AOS backend. It's by all means doable if the porter(s) are somewhat familar with C++ (fortunately wxWidgets doesn't use the really weird stuff of C++.. or at least not extensively ;) ) and of course with Intuition / Gadgets programming.. i'm not sure if a BOOPSI based approach would be usefull/feasable in the wx backend..


And regarding the bounty suggestion: I also think it is a very good bounty candidate. We just would need a proper description of the bounty and especially it's goals.. i.e. what has to be implemented and how has it to be to fullfill the bounty requirements (which also have yet to be defined).

Please have a look over in the Amigabounty.net forum which i just started and tell us your thoughts in this thread

Hello folks,

As some of you may already have seen, there is the thread "Necessary projects: (e.g. WxWidgets)" going which resulted in a suggested bounty for a port of wxWidgets. Troels and myself agree that this would really be worth a bounty as a proper port of wxWidgets would open us for a lot of fresh software instantly or with far less porting effort.

Just to name a few wxWidget users:

- AudioEvolution 5 (until v4 also on AOS, now driven by wxWidgets and so only avaibale for 'the others')
- VLC (wxWidgets would us instantly give the GUI. Of course, there still would be enough to be ported left ;) )
- Code::Blocks (an IDE)
- etc.. see Google or the wxWidgets page for more


Now we want to ask you for your thoughts about how this bounty should actually be shaped. For a successfull bounty, there have to be a good description of the requirements to fullfill the bounty, so please think about these basic questions and share your thoughts, thank you:

- What is the goal of the bounty?
I don't mean something like "a port of wxWidgets". We know that already ;) But more precisely, what shall this port be able to do to fullfill the bounty? wxWidgets consists out of many smaller specialized parts.. not only GUI stuff, but also networking, audio and whatnot. While there are many applications which just use wxBase, there are also many which uses more than one or even all featured modules of wxWidets. So we need a well defined goal. Maybe something like "the AOS port of wxWidgets must be usable to compile a working copy of <HelloWorld>" or something.

Of course, as a complete wxWidgets port is really much work, we shouldn't place a "killer-app" in place of <HelloWorld>, but something realistic.. which also leads to the next even more technical question:

- Which modules of wxWidgets have to be ported?
See above. Just a bit more refined here.

- Which timeframe should be given?
I personally think it's important to define a timeframe for a bounty and to cancel the bounty and refund the donations if the timeframe can't be hold (one or another day more shouldn't be a problem of course). Otherwise a bounty could run for years or ad infinitum which wouldn't help any of us.

- Timeframe and requirements for intermediate milestones?
I also think such a fairly big project has to be divided into milestones, which maybe can even be released as intermediate versions until the full bounty is done. This is of course only to answer after the overall goal and timeframe is set..

- Would it be a good idea to dived the bounty further in even more than one bounty?
As said, wxWidgets is huge.. so maybe it would make sense to think about dividing wxWidgets into several bounties. E.g.
wxBounty #1: Port of wxBase + wXwhatnot, app X has to be compilable with the port and actually work.
wxBounty #2: Port of wxAudio, app Y has to ...

You got the point..
I'd even say this question is highly related to the goals of this bounty.. and i wouldn't do 10 different bounties right now, but one bounty after each other for wxWidgets.. first get all the basic stuff, then open a new bounty for other parts (audio, networking, whatever).




Ok, thats all for now .. i surely forgot one or another important question to ask, so if you think about it, tell it here too

@Chris

Hm, while i'm somewhat seeing your point I could argue that the application knows it's state and has to unhide itself if needed :)

But I'll have a look at the docs and see if a fix is really needed.

Edit: can you point me to an application with which I can reproduce your findings please? And a small step by step guide would be nice too. Thanks.

@Troels

Well, i'd say "This is a support forum for www.amigabounty.net and all the bounties hosted there, like Allegro and Sputnik ATM"

@ all

Please post any feedback to the site here, we really appreciate all your input. Just remember that the site is still in BETA stage, so some issues will be there for sure ;)

@Chris

Just a small update to the pattern matching issue: The pattern matching code was actually exchanged by a developer who isn't in the OS4 team anymore.. it was in the early days of OS4, probably during conversion from ASM DOS to C source..

Anyway, that code is a hell of a bitch (a lot of recursion and other nice gems) which isn't easy to fix. I had a look myself and headache started right after the first minutes starring at the code.. :-/

I have it on my ToDo list and if noone beats me to it, i'll try to fix it at some point, but i'll have to have a *lot* of free time then only to understand the code(design) to know where i have to fix something..

So, sorry to say: don't hold your breath..

@Chris

Quote:

Oh please no more conspiracy theories I just meant hopefully "in time" for the next public update (whatever and whenever that will be) .. this bug is really old enough already.

@Chris

Quote:

Hm... I remember investigating that ages ago and even started to work on it.. Or at least it was on my todo list. I'll recheck with Colin to get this finally fixed, hopefully in time.

@Chris

could you please cook up a small test app which clearly shows the behavior and provide the source?

That way Tony or myself can file a proper bugreport for the ASL maintainer who needs to reproduce this.

Thank you.

@ShInKurO

Quote:

Can't reproduce that here.. but maybe it will show up while i'm working on another issue with clock.docky.

Quote:

I'll check that... i *think* i know what's causing that, but i'm not sure i can fix it without major rewrites of AmiDock (which i surely won't do).

Quote:

That's not a problem of AmiDock.. every (app)docky is free in its decision if it reacts on single- or doubleclicks. AmiDock just informs the docky about what happened, but the Docky itself is responsible to react to the action.

So if one docky opens a window on single click and another docky only after doubleclick, it was the decision of the dockycoder to do it that way and not AmiDocks.

Quote:

We are at OS4.1 meanwhile.. ;)