Forums - All Posts - The Amigans website

Forum Index

Board index » All Posts (joerg)

Bottom

« 1 ... 55 56 57 (58) 59 60 61 ... 101 »

joerg

Re: Way is there 3 prefs programs for Language settings?

Posted on: 2014/3/4 16:55 #1141

Home away from home

@LiveForIt

Quote:

What your saying is that struct InputPrefs -> ip_KeymapName will not always have this value?

Just look in KEYMAPS:, about 1/3 the files don't include a charset in the name.

Quote:

Maybe the Keymap is broken, but I don't see anything wrong whit it, I can see and read æ,ø,å,Æ,Ø and Å glyphs, when I write

You are trying to use a keymap in ISO-8859-15 with a system using ISO-8859-1 as charset. Most of ISO-8859-1 and ISO-8859-15 are the same, IIRC 8 chars changed. To check that it doesn't work you have to type a char which is different in both charsets, for example the Euro sign (€, ALT-e), which is in your ISO-8859-15 keymap, but can't work on your ISO-8859-1 system.

Topic | Forum

joerg

Re: Way is there 3 prefs programs for Language settings?

Posted on: 2014/3/4 15:31 #1142

Home away from home

@LiveForIt

Quote:

I think you can argue all day long, but they are not the same, some times a picture tell more then 1000 words.

https://dl.dropboxusercontent.com/u/69 ... _THIS_IS_OS_BUG_HA_HA.PNG

No matter how much you ignore it it's still an user error, your settings are broken, you use ISO-8859-1 as charset (english_ISO-8859-1 instead of english_ISO-8859-15 as first language in Prefs/Locale) but a keymap in ISO-8859-15 which obviously can't work with it. The "CountryName" your broken program displays is just the file name of the non-working keymap file (KEYMAPS:n_ISO-8859-15) you are currently using.

Topic | Forum

joerg

Re: Way is there 3 prefs programs for Language settings?

Posted on: 2014/3/4 2:28 #1143

Home away from home

@LiveForIt

Quote:

I want the encoding that is the same as if type on the keyboard, so Input Prefs one is correct one for me,

There is none, the charset encoding is set by Prefs/Locale, it's the only charset setting and used for everything, incl. keyboard input.

But you have to select a keyboard mapping using the same charset in Prefs/Input, therefore the charset is displayed there and there are different keymap files, for example Norwegian for ISO-8859-1 and for ISO-8859-15.

Quote:

I use English menus in workbench and programs, but use a Norwegian keyboard settings.

You have to select english in ISO-8859-15 ("english (€)") instead of english (using ISO-8859-1) as first language in Prefs/Locale. With your current prefs for example ALT-e doesn't work, with the Norwegian ISO-8859-15 keymap it's the € but since you have selected the wrong charset in Prefs/Locale it's wrong and can't be displayed.

Topic | Forum

joerg

Re: Solved; IScoket->Connect(...) not working from proc = IDOS->CreateNewProcTags(...)

Posted on: 2014/3/3 18:23 #1144

Home away from home

@LiveForIt

Quote:

So is the documentation wrong?

Partially, it seems it just wasn't updated when SocketBase sharing was added, before it was added to RoadShow each process had to open it's own SocketBase and the only way to use sockets in different processes was to move a socket from one SocketBase to another one using ReleaseSocket() (removes it from the SocketBase used by the current process, usually the parent process) + ObtainSocket() (adds it to the SocketBase used by the current process, usually a child process of the one which released the socket).

Quote:

There is also number of references to fd (file descriptor), not sd (socket descriptor), in the autodocs.

Some of the docs were probably taken directly from the docs of the BSD4.3 TCP/IP stack on which RoadShow is based without changes, on Unix (and in the AmigaOS C library functions) there is no difference between file and socket descriptors.
The error defines can't be changed, for example from EMFILE to EMSOCKET, or it would be incompatible to other systems.

Topic | Forum

joerg

Re: Solved; IScoket->Connect(...) not working from proc = IDOS->CreateNewProcTags(...)

Posted on: 2014/3/3 17:54 #1145

Home away from home

@LiveForIt

Quote:

its in the name socketfd = socket file descriptor.
it's inheritance a socket, really is file descriptor, but you don't think about it that way.

The bsdsocket.library sockets aren't stored in a process specific structure but in the SocketBase, but you can't use them from a process other than the one which called IExec->OpenLibrary("bsdsocket.library", ...), unless you enable SocketBase sharing with SBTC_CAN_SHARE_LIBRARY_BASES.

Topic | Forum

joerg

Re: Odyssey 1.23 progress

Posted on: 2014/3/3 17:40 #1146

Home away from home

@kas1e

Quote:

Btw, your old owb done with -DWTF_USE_PTHREADS=1 and -DENABLE_JSC_MULTIPLE_THREADS=1 or without ?

Which of the old OWB versions, 1.21 or 2.20?
The current version of OWB is build with WTF_USE_PTHREADS=1, HAVE_PTHREAD_RWLOCK=0, ENABLE_JSC_MULTIPLE_THREADS=0, ...

Topic | Forum

joerg

Re: Way is there 3 prefs programs for Language settings?

Posted on: 2014/3/3 16:55 #1147

Home away from home

@LiveForIt

Quote:

No the Language settings under local does not set the codepage, it sets the Language your program displays.

It sets the codepage as well, the one from the first language is used. To change the codepage you have to clear all selected languages, only if the list is empty the codepages are displayed for the languages, and use one with the codepage you want as the first one.

Topic | Forum

joerg

Re: Way is there 3 prefs programs for Language settings?

Posted on: 2014/3/3 16:38 #1148

Home away from home

@salass00

Quote:

Another solution that should work would be to use IDiskfont->GetDiskFontCtrl()

NOTES
[...]
This function should never be called by the average
user. Its sole purpose is to provide the font
preferences editor with data about the current diskfont
settings. It should not be called for other purposes.

Topic | Forum

joerg

Re: Way is there 3 prefs programs for Language settings?

Posted on: 2014/3/3 16:34 #1149

Home away from home

@LiveForIt

Quote:

what I was really looking for some way to find codepage encoding,

struct Locale *locale = ILocale->OpenLocale(NULL);
uint32 codeset = locale->loc_CodeSet;
ILocale->CloseLocale(locale);

Quote:

so I can use it whit iconv_open(),

STRPTR mimename = IDiskFont->ObtainCharsetInfo(DFCS_NUMBER, codeset, DFCS_MIMENAME);

Quote:

as I did not find a native Amiga API for encoding.

AFAIK there are no other functions than the iconv ones, but for converting from/to unicode you can use the DFCS_MAPTABLE from IDiskFont->ObtainCharsetInfo().

Topic | Forum

joerg

Re: What is the correct tecnique to determine if two files are on the same volume under AmigaOS 4.x?

Posted on: 2014/3/3 1:35 #1150

Home away from home

@broadblues

Quote:

I need to upgrade a function in a project I'm working on to AmigaOS 4.

This is the old code.

Not just old, ancient Kickstart 1.x code

Since AmigaOS 2.0 it's something like


static BOOL OnSameVolume(STRPTR fname1, STRPTR fname2) 

{ 

    BPTR lock1, lock2;

    BOOL result = FALSE;



    lock1 = IDOS->Lock(fname1, ACCESS_READ);

    lock2 = IDOS->Lock(fname2, ACCESS_READ);



    if (lock1 && lock2)

    {

       int32 same = IDOS->SameLock(lock1, lock2);

       if (LOCK_SAME == same || LOCK_SAME_VOLUME == same)

       {

          result = TRUE;

       }

    }

    

    if (lock1) IDOS->UnLock(lock1);

    if (lock2) IDOS->UnLock(lock2);



    return result;

}

Edited by joerg on 2014/3/3 1:55:31

Topic | Forum

joerg

Re: Odyssey 1.23 progress

Posted on: 2014/3/1 17:36 #1151

Home away from home

@kas1e

Quote:

About what i curios now also , is about that tc_ETask stuff in the http://kas1e.mikendezign.com/temp/findtask/MachineStackMarker.cpp

(see morphos ifdefs there)

As long as it's only in OS(MORPHOS) parts and you don't add the same in OS(AMIGAOS) parts, which of course couldn't work, it doesn't matter.
Either you are currently building Odyssey with USE_PTHREADS enabled, or this file isn't used at all or you'd get a compiler error from
#error Need a way to compare threads on this platform

Topic | Forum

joerg

Re: Odyssey 1.23 progress

Posted on: 2014/3/1 2:25 #1152

Home away from home

@LiveForIt

Quote:

The code you quoted has a few bugs.

t->tc_UserData = (struct MinList *) malloc(sizeof(struct MinList));

should be.

t->tc_UserData = (struct List *) IExec -> AllocSysObject(ASOT_LIST, TAG_END);

No, it should be
t->tc_UserData = IExec -> AllocSysObject(ASOT_LIST, ASOTLIST_Min, TRUE, ASO_NoTrack, FALSE, TAG_END);
(struct MinList *) or (struct List *) casting for setting tc_UserData makes no sense.
It should be a MinList instead of a List to be compatible to the rest of the MorphOS code, and enable resource tracking because it's probably never freed again, if it would be freed somewhere not setting tc_UserData to NULL there would be very strange.

Quote:

so *key should be a (struct *Node) type,

It has to be a MinNode, if the struct ThreadSpecificNode in the comment is the one which is actually used, allocated with IExce -> AllocSysObject(ASOT_NODE, ASONODE_Min, TRUE, ASONODE_Size, sizeof(struct ThreadSpecificNode), TAG_END);

In case it's not guaranteed that all ThreadSpecificNode are freed additionally with ASO_NoTrack, FALSE.

Quote:

there for malloc() is wrong command to allocate the memory, because malloc() was private memory, and t->tc_UserData comes from outside the process.

Not in threadSpecificKeyCreate() and threadSpecificKeyDelete(), both use t = FindTask(NULL) and malloc()/MEMF_PRIVATE could be used. For using IExec->AllocSysObject() with ASO_NoTrack, FALSE it's required that allocating and freeing is done in the same process as well or the destructors would be called when a different process ends.

Topic | Forum

joerg

Re: Odyssey 1.23 progress

Posted on: 2014/2/28 17:57 #1153

Home away from home

@Fab

Quote:

So, OS4 is incompatible with AmigaOS 3.x?
Many programs use tc_UserData. tc_UserData is meant to be *used* by the programs, not by the operating system (hence the name).

It's not a bug in AmigaOS but in Odyssey (maybe in Roman's parts only), it obviously crashes if tc_UserData wasn't NULL when it's started.

AmigaOS still doesn't use tc_UserData itself.

Topic | Forum

joerg

Re: Odyssey 1.23 progress

Posted on: 2014/2/28 17:51 #1154

Home away from home

@kas1e

Quote:

On exit, tc_UserData still have that value from odyssey, but with FindTask(NULL)->tc_UserData = NULL; at main there no crash anymore.

Instead of setting it to NULL at the start of main() you should do it at the end. It's the same for Odyssey, but other software might have the same problem if you don't set it to NULL. Or even better at the start and at the end, in case someone runs another program in a shell which doesn't clear it on exit before Odyssey.

And of course you should fix the actual bug in Odyssey as well.

Topic | Forum

joerg

Re: Odyssey 1.23 progress

Posted on: 2014/2/28 16:33 #1155

Home away from home

@kas1e

No idea what it is, but "MUI imagespace screen notify" child process is still running after exit, and it's still waiting for some signals which shouldn't happen either.

Using something like Scout instead of Ranger would be better, it includes much more things from struct Process like the Input(), Output() and ErrorOutut() files (pr_CIS, pr_COS and pr_CES), current directory lock, etc.

Topic | Forum

joerg

Re: Odyssey 1.23 progress

Posted on: 2014/2/28 15:40 #1156

Home away from home

@broadblues

Quote:

I would suggest you go through all amiga specific structure allocations and check they are all the right size, there's an outside chance of an allocation of a pointer to struct rather than a struct or something like that. (ie sizeof(struct foo*) instead of sizeof(struct foo) very easy mistake to make and hard to spot ... and you rarely get a DSI from such errors.

If it would be something like that he'd get random crashes no matter how he starts Odyssey, but not never crashes for the 1st run and always for the 2nd in the same shell.

Some cleanup seems to be missing somewhere which results in destroying something, or even more likely setting it to some data of Odyssey which is freed after exit, in struct Process or something else the shell is using.

@kas1e
Use tools like Ranger or Scout to check the struct Process of the shell you are using for starting Odyssey, nothing must change after the 1st run but something probably does. Knowing what is trashed would help a lot.

Topic | Forum

joerg

Re: Odyssey 1.23 progress

Posted on: 2014/2/28 15:30 #1157

Home away from home

@kas1e

initializeThreading() seems to call a lot of functions just to initialize static data in these functions, which shouldn't be required, at least in the ones included in the sources there is nothing which can only be done from the main thread.
But if there is a bug somewhere which requires doing that for some strange reason you probably have to do it for everything, for example add threadMap(); syncPortMap(); threadReplyStateMap(); in initializeThreading() as well.

Why are you using
#ifdef __amigaos4__
static Mutex* atomicallyInitializedStaticMutex=NULL;
#else
static Mutex* atomicallyInitializedStaticMutex;
#endif
?
That makes no sense either, but since you added it there must have been something seriously wrong somewhere which required doing it, for example a buffer overflow writing to some .bss data and adding =NULL moved it to the .data section and now something else in .bss is trashed instead.
What was the reason you did that?

Topic | Forum

joerg

Re: Odyssey 1.23 progress

Posted on: 2014/2/28 11:12 #1158

Home away from home

@kas1e

Quote:

So on wtfThreadData(); , which is here:
http://kas1e.mikendezign.com/temp/threading/BCWTFThreadDataWTF.cpp

If USE(WEB_THREAD) is enabled you are mixing MorphOS threading with pthreads threading: if (pthread_main_np() ...).
And the wtfThreadData() function isn't there, it's probably in the include file.

Topic | Forum

joerg

Re: Odyssey 1.23 progress

Posted on: 2014/2/28 11:05 #1159

Home away from home

@Georg

It could be anything, something in struct Process overwritten, or in struct CommandLineInterface, dos.library Input()/Output() files replaced by Odyssey but not restored on exit, ...
As long as Roman doesn't build his executables with debugging information (-gstabs) and checks where exactly it crashes and what it's doing there on the 2nd run it's impossible to find out what it is.

Topic | Forum

joerg

Re: Odyssey 1.23 progress

Posted on: 2014/2/28 10:58 #1160

Home away from home

@kas1e

Quote:

Yep, have crash if i just run odyssey, then close, and then run joerg's owb for example. Crashlog:

I don't understand why you don't debug your own executables, but this crash in OWB 3.32 is an intentional crash (accessing 0 in an internal exception handler used for example for debugging deadlocks) and therefore useless to find your bugs in Odyssey. Except that Odyssey returns with the SIGBREAKF_CTRL_E signal set, which it shouldn't do.

Topic | Forum

Top

« 1 ... 55 56 57 (58) 59 60 61 ... 101 »