Who's Online |
67 user(s) are online ( 36 user(s) are browsing Forums)
Members: 1
Guests: 66
orgin,
more...
|
|
|
|
Re: Is Tunenet station scan out again?
|
Posted on: 2011/9/29 9:43
#141
|
Quite a regular
|
@Mickey_C
the problem here is not Tunenet but shoutcast.com changing again its servers...
In fact Tunenet is a part of the problem because it's using old shoutcast API which shoutcast wants to fade out (of course because the new API v2 requires payed registration by the application devs)
|
Back to a quiet home... At last
|
|
|
Re: What happened to Qt??
|
Posted on: 2011/9/28 13:54
#142
|
Quite a regular
|
Quote: ChrisH wrote: KOffice was suggested], but I suspect that some smaller stuff would be worth doing first!
Not to say that before porting any KDE apps one would first have to port KDElibs which is another layer on top of Qt...
|
Back to a quiet home... At last
|
|
|
Re: Major problem with FTPMount and Update 3
|
Posted on: 2011/9/14 10:52
#143
|
Quite a regular
|
As the AOS4 FTPMount maintainer I can tell you that FTPMount is doing all sort of strange things, so the culprit is probably not dos.library but rather FTPMount. I'd like to improve that by releasing a new version but I'm stuck with a stupid bug triggering at startup which I can't track down for months.
Anyway I'll try to see if I can find the origin of this alert.
PS: you might want to contact ChrishH as he also seems to be a regular user of FTPMount.
|
Back to a quiet home... At last
|
|
|
Re: AmigaOS Version
|
Posted on: 2011/9/12 9:16
#144
|
Quite a regular
|
Quote: djrikki wrote: Discovered a way how to get the AmigaOS textual version string. Not bullet-proof as I know people love to tinker with stuff they shouldn't, but it works well for the project I am working on which is information based. If you need to be absolutely precise I suggest you follow Hans' approach kindly provided by Derfs link.
SYS:kickstart/kicklayout
Open this in Notepad and you will notice a line beginning with 'LABEL AmigaOS' after this the textual version follows.
How do I find this? Simple.
Find dirs dh0: contents 'update 3' so bloody easy in the end lol
This file *is* user configurable and will be for example on almost all betatesters systems. Because it allows to fine tune which module is loaded or not, it also allows to load debug kernel and/or modules etc. So in effect you might as well end-up with multiple lines starting with 'LABEL' because in the end this is only what it pretend to be : a *label* that is only used for display at the system loading (i.e. in UBoot or CFE). Good luck with such trick to have a reliable result...
|
Back to a quiet home... At last
|
|
|
Re: AmiSystemRestore - beta testers wanted!
|
Posted on: 2011/9/2 9:54
#145
|
Quite a regular
|
@nexus
Yes we have filesystem notification but for what ChrisH is trying to do (i.e. backup any changing file, so that you are able to restore it in case of problem) this is too late because the modification already happened when you get the notification.
So the only solution currently is to 'patch' some strategic OS functions using Exec/SetMethod() in order to intercept calls to those functions do what you have to (i.e. save states and make backup) and then leave the control to the original OS function.
That's risky because if your code is buggy you can completly prevent execution of the normal OS function thus making your system's behaviour totally unpredictable.
|
Back to a quiet home... At last
|
|
|
Re: AmiSystemRestore - beta testers wanted!
|
Posted on: 2011/9/2 8:14
#146
|
Quite a regular
|
Quote: rwo wrote: Nice..
But why would you have it running all day? and why do you need to patch OS4?
To be able to detect file alterations you need to "patch" DOS calls like Open() or Write(). I did some experimentation myself some time ago, the crucial point is not to get the performances down at the same time.
|
Back to a quiet home... At last
|
|
|
Re: APod - modules
|
Posted on: 2011/8/29 8:35
#147
|
Quite a regular
|
Your makefile is faulty or incomplete. It seems make is trying to build something called 'DYNAMIC' but can't find any rule to make it.
|
Back to a quiet home... At last
|
|
|
Re: Happy Birthday Hans-Joerg and Thomas!
|
Posted on: 2011/8/15 11:35
#148
|
Quite a regular
|
Hmm Hans-Joerg & Thomas, Trevor were born the same day as me ? So happy birthday to all of us then PS: thank you TSK.
|
Back to a quiet home... At last
|
|
|
Re: Internal version number of OS4.1.1?
|
Posted on: 2011/7/29 14:31
#149
|
Quite a regular
|
Quote: kas1e wrote: Btw, why exec, and not version.library as Cyborg point?
Maybe because exec.library is already open and thus don't need additionnal code just to check which version the OS is?
|
Back to a quiet home... At last
|
|
|
Re: Public screen closing bug in OS4.1
|
Posted on: 2011/6/16 15:57
#150
|
Quite a regular
|
Quote: xenic wrote: The problem is with Ringhio and not Intuition or Screens preferences and I think that patching CloseScreen() is a misguided attempt to compensate for a Ringhio problem. Without Ringhio, my public screens (whether program created or Screen prefs created) all work as they should. I think Ringhio should use system compliant requesters instead of the current method.
I agree with you patching CloseScreen() so that it never fails might not be a good idea because this means that some programs that rely on the fact that CloseScreen() returns immediately might get stuck for ever without being prepared of this... *If* it's a bug in Ringhio let's fix Ringhio not Intuition. EDIT: removed some stupidity.
|
Back to a quiet home... At last
|
|
|
Re: New amigans.net bugs
|
Posted on: 2011/5/20 10:58
#151
|
Quite a regular
|
Two small things: - OS4depot files section never works it always ends to a page saying "Could not open file. Report error to site owners." - The report button is missing
|
Back to a quiet home... At last
|
|
|
Re: Datestamp issue (Was: XAD LhA still has datestamp bug)
|
Posted on: 2011/5/20 10:53
#152
|
Quite a regular
|
@ChrisH Quote: ChrisH wrote: @MickJT Quote:So I guess I just never noticed before. 20 years of not noticing :-/ Not necessarily. In OS4.1 (if not earlier) they change the behaviour of date stamps on folders:
Before that AmigaOS only updated the date stamp for changes immediately inside the folder. i.e. Changing the file given by the path "Volume:One/Two/Three/File" would only change the date stamp of folder "Three".
But after that AmigaOS (at least for some filing systems) updates the date stamp OF ALL CONTAINING FOLDERS all the way. i.e. Changing the file given by the path "Volume:One/Two/Three/File" would change the date stamp of folders "Three", "Two" AND "One".
If XAD/LhA were written with the former folder behaviour in mind, then they **might** have set the folder date after extracting all the files in the immediate folder. That would have avoided new files causing the folder's date to change. But with the newer folder behaviour, this "work-around" would no longer work reliably.
IMHO it's not >AmigaOS< responsible for that but the underneath FileSystem. And to my own memories FFS2 always featured this like that. Maybe SFS/SFS2/JXFS did not until OS 4.1 I don't know.
|
Back to a quiet home... At last
|
|
|
Re: Stuck in deconstructor??
|
Posted on: 2011/5/12 14:08
#153
|
Quite a regular
|
@Mrodfr
In fact the crash looks very different than Alfkil's one. In yours the problem seems to lie in one of the thread (created from pthreads) when its trying to call a newlib function while in the SetProgressLabel() method of the class PostInfo. Most probable issue is that the thread is using a global variable which value changed or worst was disposed... At least it's what it seems to me looking at the crash log you are exposing.
|
Back to a quiet home... At last
|
|
|
Re: Stuck in deconstructor??
|
Posted on: 2011/5/12 11:10
#154
|
Quite a regular
|
May be the solution would be to have static objects/classes to use their own instance of pthreads.library rather than relying on an externally opened instance ?
Note: that I don't know if pthreads.library allow sharing threads accross library instance (but that would be really dumb not to do this)
|
Back to a quiet home... At last
|
|
|
Re: WxWidgets bounty status request
|
Posted on: 2011/5/3 8:41
#155
|
Quite a regular
|
@kas1e
Don't knowing Reaction is a drawback because I have to make choices on very low level that would have consequences latter when I'll want to implement native widgets. But anyway I'll try to do a resume and I'll contact you by email. In the meantime if you want I can tell you what to look at.
@Troels
Yes any help would be appreciated.
@Hans
Indeed it's the plan. In fact the real plan is two steps : 1) implement very low level graphical classes (that is wxDC, wxPen, etc.) so that we will be able to run wxUniversal (it's a universal implementation of the main widgets only using the low level class, i.e. using *non* native GUI) 2) replace widgets one by one by native ones (when it's possible)
Note that for 1) the idea is also to implement an AmigaOS theme so that wxUniversal would look (almost) identical to a native GUI.
|
Back to a quiet home... At last
|
|
|
Re: WxWidgets bounty status request
|
Posted on: 2011/4/29 8:29
#156
|
Quite a regular
|
@kas1e
The help from the other programmer eventually never materialized. This really hurt my motivation and my progress because he would have been very helpful with his graphical knowledge that I'm missing. In the meantime I'm working on a smaller project which might help me increase my knowledge of Reaction (CompareDir also serves this goal).
|
Back to a quiet home... At last
|
|
|
Re: Desperately in need of a working debugger
|
Posted on: 2011/4/28 8:38
#157
|
Quite a regular
|
@Raziel
Maybe because non AOS4 developpers don't know how to read a Grim Reaper log nor they know how to produce an executable embedding correct debug information to help them.
Grim Reaper log will tell you what was the location of the crash. On the other hand a debugger will tell you why the crash occured, but for that you must : - have a relative knowledge of what the program is supposed to do and how; - have an AOS4 debug friendly executable (i.e. an executable generated with correct AOS4 debug information). This means that a debugger is reserved to *programmers* not to end users.
If you want think to a car and the diagnostic box garage owners have to find problems in cars. Now imagine you, as a car end user, manage to obtain such a diagnostic box it obvious that to find where the problem is : - you have to be sure the car is compatible (i.e. right brand) with the diagnostic box you have, - you have to know how to use the box, how it should read for the specific car model you have and how to interpret results.
|
Back to a quiet home... At last
|
|
|
Re: Float display
|
Posted on: 2011/4/19 10:37
#158
|
Quite a regular
|
@Tonyw
Okay there was a problem at a time and it was best to avoid mixing calls (I agree snprintf has nothing to do with DOS calls but as I stated it was just a way to be on the safe side). *Now* maybe there is no problem anymore and maybe OS components safely mix calls from C Runtime and native one.. But :
- as third party developpers we don't have access to OS component code to be able to see it by ourself, - there is no *official* (or at least acknowledged by OS programmers, paid or unpaid) Programmer Best Practise guide (not no speak about RKM) where such a thing would have been written,
As a consequence we (I) have no way to know this can now be done and is now safe.
Speaking about the duplication I don't agree with you it would have seemed to me more logical to have the feature in native and have C runtime as a wrapper around that than the reverse (how about the locale settings took into account for example). But *you* are OS developer and I am not so you might have insider information that I don't have. Please read this the right way there is no baiting in it nor anger. I'm just expressing my POV and respect yours; now that I have confirmation from an OS developer that it's safe then I'll use snprintf()
|
Back to a quiet home... At last
|
|
|
Re: Float display
|
Posted on: 2011/4/18 8:19
#159
|
Quite a regular
|
Quote: tonyw wrote: OK, I'll ask the question a different way - why use IUtility->SNPrintf() at all, if it doesn't do what you want (floating point) ?
I didn't know SNPrintf was not doing what I wanted until I noticed it... Quote: By "native" calls, I suppose you mean AOS-centric calls? Why restrict yourself to AOS-centric calls? Why not use the standard, built-in C library that's already there? No one is going to think less of you if you use built-in calls and external-library calls in the same module.
Maybe I'm missing the point, but I don't understand your reluctance to use the standard tools provided.
There was a time when mixing DOS I/O calls with C runtime I/O calls wasn't a good idea since then I try to not mix them as safety measure.
|
Back to a quiet home... At last
|
|
|
Re: Float display
|
Posted on: 2011/4/15 14:09
#160
|
Quite a regular
|
@Tonyw *I* don't want to use IExec->RawDoFmt() but IUtility->SNPrintf() does I have nothing against snprintf() and portability but I try to not mix ANSI and native calls in the same program.
|
Back to a quiet home... At last
|
|
|