Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
55 user(s) are online (41 user(s) are browsing Forums)

Members: 2
Guests: 53

Georg, Maijestro, more...

Headlines

Forum Index


Board index » All Posts (msteed)




Re: Double heigh screen and normal window on
Just popping in
Just popping in


@kas1e

Quote:
Thanks for point, i tried, but it's the same :(

Hmm, I was hoping that would help. Can you at least move the window to the proper location with MoveWindow() or ChangeWindowBox() after it's been opened?

Go to top


Re: Double heigh screen and normal window on
Just popping in
Just popping in


@kas1e

Perhaps WA_AutoAdjust is altering the location of your window? Here's what the autodocs have to say about it:

Quote:
WA_AutoAdjust - a Boolean attribute which says that it's OK
to move or even shrink the dimensions of this window
to fit it on the screen, within the dimension
limits specified by MinWidth and MinHeight.
Someday, this processing might be sensitive to the
currently visible portion of the screen the window
will be opening on, so don't draw too many conclusions
about the auto-adjust algorithms. Also see WA_AutoAdjustDClip
below.
(Normally, this attribute defaults to FALSE. However,
if you call OpenWindowTags() or OpenWindowTagList()
with a NULL NewWindow pointer, this attribute defaults
to TRUE).

Since you're not using a NewWindow, WA_AutoAdjust defaults to TRUE. It might be confused by the double-height screen, and ends up putting the window where it thinks it's visible. Try adding WA_AutoAdjust, FALSE, and see if that helps.

Go to top


Re: MineCraft (MineTest) work in progress help need it
Just popping in
Just popping in


@kas1e

I'd assume that for compatibility reasons malloc() uses MEMF_SHARED. If it didn't, you'd expect to get a DSI when some other task/thread tried to access the semaphore.

Quote:
But what Andrea mean it should be something like :

You could also allocate the entire isem_t using AllocVecTags(), instead of just the SignalSemaphore. That way, you wouldn't need to change any of the other semaphore code to work with pointers to objects instead of embedded objects (I assume you made those changes when you tested Andrea's suggestion).

SignalSemaphores (and Lists) can also be allocated using AllocSysObjectTags(), which presumably initializes them for you. You'd again be working with pointers to objects.

I suspect that none of that will make a difference, but it might be worth a try if further debugging doesn't turn up anything.

Quote:
Not sure through how/what it mean

It sounds like they're suggesting that if we have a working implementation of std::counting_semaphore (do we?) that we could look at the source code for that and see how it's implemented compared to how libpsem did it.

Go to top


Re: MineCraft (MineTest) work in progress help need it
Just popping in
Just popping in


@kas1e

Quote:
I never use anywhere posix semaphores, it is first time i meet with them in minetest. Frederik made this library exactly when i ask about in this thread and then fixing it few times.

Ah, so it doesn't have the history behind it that I was expecting. Still, from at least a casual examination of the code, I don't see anything that looks like it would cause a major system lockup, as long as it's getting valid data to work with. That's not the same as saying I'm sure there's nothing wrong with it, but I'd still check those other two possibilities first.

Quote:
Question is how to find it without debugger, what to prinfs and where.

Having a working debugger would be nice, though a hard system crash would probably kill the debugger, too.

Unfortunately, there's no simple way to check for the first possibility (corruption of the underlying sem_t). The sem_t contains embedded Exec SignalSemaphore and List structs, rather than pointers to them, so you'd need to DebugPrintF() a bunch of fields in those structs to try to determine if they are corrupt or not. You could at least dump isem->value and see if it looks reasonable (it should probably be zero).

You could also add some "made it to this point"-style DebugPrintF()s inside sem_post(), to try to determine where in that function the crash occurs.

For the second possibility (the code being triggered by the semaphore is what crashes) you'd need to locate the code that's waiting on the semaphore that's being posted to; something like "m_send_sleep_semaphore.wait()". Then you could add some "made it to this point"-style DebugPrintF()s both before and after the wait, to see if the code actually exits the wait before the crash occurs. If it does, you can move the DebugPrintF()s further along in the code to try to narrow down where the crash happens.

Go to top


Re: MineCraft (MineTest) work in progress help need it
Just popping in
Just popping in


@kas1e

The code for sem_post() isn't terribly complicated. Since the same code seems to work most of the time (and presumably in other projects as well), I'm guessing that's not where the problem lies. So two possibilities come to mind.

1. The semaphore (sem_t) that's being passed to sem_post() is getting clobbered by something. sem_post() makes a number of Exec calls, passing pointers obtained from the semaphore. If one or more of those pointers is invalid, it could potentially cause a crash.

2. Presumably there's another thread somewhere that's sem_wait()ing on the semaphore. That thread wakes up when sem_post() posts to the semaphore, and that thread does something that causes the crash. The crash is not caused by the post, it's just triggered by it.

Go to top


Re: MineCraft (MineTest) work in progress help need it
Just popping in
Just popping in


@kas1e

Quote:
But what i can see there, that it take "int" as input, and then signals semaphores, but we do call it from Trigger() without any value, just as "post()" , so maybe something wrong there ..

num is given a default value of 1 in the declaration of Semaphore:

void post(unsigned int num 1);

So if you call post() without a parameter it should use the default. You could add a printf to confirm that.

The problem is probably in the call to sem_post(&semaphore);.

Go to top


Re: Show your AmigaOS 4.x computer or Workbench!
Just popping in
Just popping in


@trixie

Hey, E-mu! I applied for a job there once, way back when.

Go to top


Re: SnoopDos causes a DSI error
Just popping in
Just popping in


SnoopDos does have a nicer user interface, though that's no help if the basic functionality doesn't work.

One SnoopDos feature I really miss on Snoopy is the ability to easily enable or disable all of the function monitors. When first starting to debug something and I have no idea what's wrong I often like to enable everything, and then disable selected functions afterwards if logging them gets in the way. That was one button on SnoopDos, but involves manually selecting a slew of items across multiple submenus with Snoopy.

It would be nice if there were "Enable All" and "Disable All" menu selections, at least for the DOS Functions menu. And perhaps a "Default Settings" (or "Saved Settings") selection as well, to easily get back to the starting point.

Go to top


Re: Internet speed test that works in Odyssey?
Just popping in
Just popping in


@ktadd

I found this one some years ago, and it's always worked well for me: testmy.net

Go to top


Re: Bug in Newlib Header?
Just popping in
Just popping in


@Raziel, @walkero

Quote:
I think that's what msteed described as a solution that worked for him as well.

Yes, that's exactly what I did.

The bug seems to be something that's rarely encountered, since it's been around for some time (it was in at least the previous version of the SDK (53.30), too).

Go to top


Bug in Newlib Header?
Just popping in
Just popping in


I believe I've stumbled across a bug in one of the newlib header files (the ones from the most recent SDK). I was trying to compile GIFLIB, where one of the files has the following bit of code:

#ifndef SIZE_MAX
    #define SIZE_MAX     UINTPTR_MAX
#endif

It compiled fine when using clib2, but when using newlib I got the following error when SIZE_MAX was referenced:

In file included from openbsd-reallocarray.c:8:
openbsd-reallocarray.cIn function 'openbsd_reallocarray':
openbsd-reallocarray.c:25:19error'ULONG_MAX' undeclared (first use in this function)
      
nmemb && SIZE_MAX nmemb size) {
                   ^~~~~~~~
openbsd-reallocarray.c:25:19note'ULONG_MAX' is defined in header '<limits.h>'did you forget to '#include <limits.h>'?
openbsd-reallocarray.c:10:1:
+
#include <limits.h>

The file indeed does not include <limits.h>, but it does include <stdint.h>. The clib2 version of <stdint.h> contains the following:

#ifndef    _LIMITS_H
#include <limits.h>
#endif /* _LIMITS_H */

So <stdint.h> includes <limits.h>, and everything works fine. The newlib version of <stdint.h>, however, contains the following:

#if defined(__GNUC__) && \
  
( (__GNUC__ >= 4) || \
    
( (__GNUC__ >= 3) && defined(__GNUC_MINOR__) && (__GNUC_MINOR__ 2) ) )
/* gcc > 3.2 implicitly defines the values we are interested */
#define __STDINT_EXP(x) __##x##__
#else
#define __STDINT_EXP(x) x
#include <limits.h>
#endif

In other words, <limits.h> is included only if the version of GCC is 3.2 or earlier. That seems odd, which makes me think that "#include <limits.h>" should come after the #endif, not before it.

I made this change, and was able to build GIFLIB without error. I recompiled a number of my other projects, and nothing seems to have been broken by the change. But the flow of system headers can be complex and difficult to follow, so I thought I'd see if others can confirm that this is a bug, or explain why it isn't.

Go to top


Re: SDL2
Just popping in
Just popping in


@Raziel

Quote:
NumLock doesn't produce a RAWKEY event, but the key itself does with different values.

Ah, I see. You're right, when a numpad key that varies with the NumLock state is pressed, it's possible to deduce the state- if you get a '0' from the numpad then NumLock must be on, and if you get an 'Insert' it must be off.

That won't work with numpad keys like '5' and '+' that don't vary with the NumLock state though, and of course someone has to press a numpad key before you can update the state. That might be good enough, depending on what you're looking to do with the NumLock state, but it's not a general purpose way to know the current state.

Go to top


Re: SDL2
Just popping in
Just popping in


@Capehill
@Raziel

It looks like the numlock key does not generate a keycode on the Amiga. At least, when I run the Input Event Sniffer (http://os4depot.net/?function=showfil ... isc/inputeventsniffer.lha) and watch for RAWKEY and EXTENDEDRAWKEY events nothing happens when I press numlock.

Go to top


Re: Why call to or any "empty" functions can cause different results of the code in which you insert it?
Just popping in
Just popping in


Quote:
"If an error is generated, no change is made to the contents of params."

Given that, it would be good defensive programming practice to set 'status' to 0 before making the call, so if the call aborts without setting the status at all then at least you'll get a consistent failure, rather than a random result depending on what happens to be on the stack. That would have saved kas1e a lot of time playing with printf().

Go to top


Re: Why call to or any "empty" functions can cause different results of the code in which you insert it?
Just popping in
Just popping in


@kas1e

What if you put the printf() or Delay() at the very beginning of your function, before making any of the SDL calls? Does it work there? What if you put it at the very end, just before the "return SDL_TRUE;"? (Which means it won't even be called if compiling the shaders fails.) Or does it have to be in between the two sets of SDL calls in order to make a difference?

And what if you use IExec->DebugPrintF() rather than printf()?

Go to top


Re: Introducing Profyler
Just popping in
Just popping in


I waited for a bit in case anything else came up, but nothing did. So I've released version 1.1 of Profyler, which adds a workaround for the bug in ObtainDebugSymbol() and so can now display the source file name and line number for every profiled function.

The workaround shuts off starting with Exec version 54.47, so hopefully the bug fix will be present in that version when it appears.

Go to top


Re: Why call to or any "empty" functions can cause different results of the code in which you insert it?
Just popping in
Just popping in


@kas1e

Remember that while printf() looks simple in the source code, there's a lot going on under the hood, involving the console (which decides where the printed text goes), the graphics library (which renders the font characters into pixels), and the graphics card driver (which gets the pixels to the screen).

Somewhere in all of that there's almost certainly something that has to Wait(), which gives other tasks a chance to run. So printf() doesn't just take some time to execute. but it also allows other tasks to run. Your for() loop takes time, but most likely doesn't cause a task switch (assuming the delay isn't so long that it's preempted). Calling Delay() of course also allows other tasks to run, without all the other complexity of printf().

I'm not a 3D graphics guru, so I have no idea what those graphics calls are doing. But if it involves another task that's running asynchronously, then letting that task run while you're delaying may give it a chance to complete some necessary work that doesn't get done in time otherwise.

Go to top


Re: Is there a simple why to find the motherboard name?
Just popping in
Just popping in


@LiveForIt

It's not precisely what you asked for, but the autodoc for version.library has this table for the version number of version.library itself:

AmigaOS release                          version.library
 
-----------------------------------------+----------------
 
3.5                                      44.2
 3.9                                      
45.1
 3.9 Boing Bag 1                          
45.2
 3.9 Boing Bag 2                          
45.3
 4.0                                      
50.2
 4.0 Update 1                             
51.1
 4.0 Update 4                             
51.4
 4.0 Update 4 
(CyberStormPPC/BlizzardPPC) | 52.2
 4.1                                      
53.1
 4.1 Update 1                             
53.2
 4.1 Update 2                             
53.3
 4.1 Update 3                             
53.7
 4.1 Update 4                             
53.8
 4.1 Update 5                             
53.10
 4.1 Update 6                             
53.11
 4.1 Update 7 
(unreleased)                | 53.12
 4.1 Update 8 
(unreleased)                | 53.13
 4.1 
Final Edition                        53.14
 4.1 
Final Edition Update 1               53.15
 4.1 
Final Edition Update 2               53.17
 4.1 
Final Edition Update 2 HotFix        53.18

Go to top


Re: Amigans.net 2022 updates
Just popping in
Just popping in


@walkero

I saw this same thing once a few days ago, when visiting as a guest (not logged in)- news items from 2006 or 2007, and if I scrolled down to the bottom of the home page the page selection buttons had me on some page number in the hundreds, instead of page 1.

I don't remember what I did to fix it- I think I just clicked on 'Home', but I may be remembering wrong. I imagine I could have clicked on the page 1 button, too.

I haven't seen the problem since, so it's not readily reproducible.

Go to top


Re: x5000 benchmarks / speed up
Just popping in
Just popping in


@geennaam

Any chance I could get a copy of your benchmark program? I'm curious what the X1000 numbers would be.

Go to top



TopTop
« 1 2 3 (4) 5 »




Powered by XOOPS 2.0 © 2001-2016 The XOOPS Project