Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
67 user(s) are online (36 user(s) are browsing Forums)

Members: 1
Guests: 66

orgin, more...

Headlines

Forum Index


Board index » All Posts (abalaban)




Re: Is Tunenet station scan out again?
Quite a regular
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
Go to top


Re: What happened to Qt??
Quite a regular
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
Go to top


Re: Major problem with FTPMount and Update 3
Quite a regular
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
Go to top


Re: AmigaOS Version
Quite a regular
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
Go to top


Re: AmiSystemRestore - beta testers wanted!
Quite a regular
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
Go to top


Re: AmiSystemRestore - beta testers wanted!
Quite a regular
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
Go to top


Re: APod - modules
Quite a regular
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
Go to top


Re: Happy Birthday Hans-Joerg and Thomas!
Quite a regular
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
Go to top


Re: Internal version number of OS4.1.1?
Quite a regular
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
Go to top


Re: Public screen closing bug in OS4.1
Quite a regular
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
Go to top


Re: New amigans.net bugs
Quite a regular
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
Go to top


Re: Datestamp issue (Was: XAD LhA still has datestamp bug)
Quite a regular
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
Go to top


Re: Stuck in deconstructor??
Quite a regular
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
Go to top


Re: Stuck in deconstructor??
Quite a regular
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
Go to top


Re: WxWidgets bounty status request
Quite a regular
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
Go to top


Re: WxWidgets bounty status request
Quite a regular
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
Go to top


Re: Desperately in need of a working debugger
Quite a regular
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
Go to top


Re: Float display
Quite a regular
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
Go to top


Re: Float display
Quite a regular
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
Go to top


Re: Float display
Quite a regular
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
Go to top



TopTop
« 1 ... 5 6 7 (8) 9 10 11 ... 43 »




Powered by XOOPS 2.0 © 2001-2023 The XOOPS Project