Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
145 user(s) are online (113 user(s) are browsing Forums)

Members: 1
Guests: 144

msteed, more...

Headlines
Recent files - OS4Depot - Your one stop for AmigaOS4 files

Forum Index

Board index » All Posts (msteed)


« 1 ... 3 4 5 (6) 7 8 »


msteed
Re: Amigans.net 2022 updates
Posted on: 2022/7/19 3:11    #101
Just popping in
Just popping in
@Raziel

Quote:
Then again, can't makefiles be wrapped with "\" to make them more readable?

Yes they can, and I always do so with my own makefiles. But when you're porting something you probably want to change as little as possible, so you're stuck with however the original makefile was written.
Go to top
Topic | Forum


msteed
Re: Introducing the Rear Window blog
Posted on: 2022/7/14 2:03    #102
Just popping in
Just popping in
@trixie

Quote:
I wonder what you'll say when you see the updated file requester that I'm getting ready for the upcoming version 1.2

I'm aquiver with anticipation!
Go to top
Topic | Forum


msteed
Re: Amigans.net 2022 updates
Posted on: 2022/7/11 8:01    #103
Just popping in
Just popping in
@walkero

Thanks for looking into this. The problem thread is much easier to read now with Odyssey.

It will probably vary with the fonts in use and how the browser is configured, but for me the code box is wide enough to fit more than 100 characters before wrapping. So it's unlikely to wrap when displaying actual source code. It's just stuff like makefiles with extremely long lines that will wrap, and they're easier to read when wrapped than source code.
Go to top
Topic | Forum


msteed
Re: Amigans.net 2022 updates
Posted on: 2022/7/8 2:29    #104
Just popping in
Just popping in
@nbache

Quote:
But probably the right place to solve it would be if Odyssey could learn to use word-wrap in the boxes and therefore not extend the page width.

I think the lack of wordwrap is intentional, as it would mess up the source code formatting and make it both hard to read, and hard to copy and paste. Check out OS4 Coding for examples of source code with wordwrap.

The vertical height of a source code box is limited to a reasonable value, and if the code is longer than that, it gets a vertical scroller. It should work the same way for the width of the box, which would both avoid the very wide pages, and preserve the source formatting. You'd still have to scroll back and forth to read long source lines, but at least the accompanying message text would be easily readable.

@walkero

I also notice that when the page with the problem thread is first loaded the message text is at the left, and the source code boxes have horizontal scrollers. But after a second or so the page refreshes (perhaps when it finishes loading) and takes on its problematic form. There isn't time before the refresh to scroll around and see what else is different.
Go to top
Topic | Forum


msteed
Re: Amigans.net 2022 updates
Posted on: 2022/7/7 21:47    #105
Just popping in
Just popping in
@walkero

Quote:
What browser do you use to visit amigans?

I use Odyssey. IBrowse also exhibits the problem, though it does not have the source code in a scrollable box.

@levellord

I have seen very wide pages before when source code quoting is used. But this particular thread also has the message text far away from the left edge of the page, which is something new. Perhaps triggered by the great width of some of the source code quotes (message 11, in particular).
Go to top
Topic | Forum


msteed
Re: Amigans.net 2022 updates
Posted on: 2022/7/7 7:23    #106
Just popping in
Just popping in
@walkero

Is there anything that can be done about the formatting of threads like this one: https://www.amigans.net/modules/newbb/viewtopic.php?topic_id=8871?

Unless you've got a reeeaaallly wide screen monitor it's difficult to follow the thread.

Maybe a horizontal scroller on the source code box, similar to the vertical one? Or at least get the message text to be properly left-justified.
Go to top
Topic | Forum


msteed
Re: ZitaFTP Server
Posted on: 2022/7/7 6:55    #107
Just popping in
Just popping in
libz.so.1 is a softlink to libz.so, so perhaps the link got broken somehow.
Go to top
Topic | Forum


msteed
Re: Introducing the Rear Window blog
Posted on: 2022/6/28 4:34    #108
Just popping in
Just popping in
Thanks to quick database work by Matthew -- on a Sunday, even -- I've been able to download all the updated Enhancer Core components and give Rave a try.

Very nice! Even the file requester is impressive. And this is just the first pass- I'm sure it's going to get even better as it gains features.

I didn't have any audio samples readily at hand, so I used the sounds that came with Codebench for testing. I quickly discovered that the second half of two of those sounds is basically blank, making them twice as large as they need to be. I trimmed off the blank part and saved the rest; they sound exactly the same, but are half the size. So Rave has proven useful already!

I'd have to agree with the others that I miss an undo feature. The lack of one inhibits experimentation, as if you do something you don't like you're stuck with it. But I also see the point about the memory requirement of undo when editing large samples.

Perhaps a "revert" feature, which reloads the sample from disk, could fill some of the functionality of a full undo, though frequent saving of the sample could also be an issue if using a lossy compression format, since every save and reload loses some fidelity.
Go to top
Topic | Forum


msteed
Re: Introducing the Rear Window blog
Posted on: 2022/6/25 2:26    #109
Just popping in
Just popping in
@trixie

Thanks for your latest blog entry (as well as all the previous ones). It's always helpful to read how other programmers view and approach things, and to compare it with my own views and approach. And equally helpful to see what kinds of problems other programmers encounter with their projects.

Although I don't have a great need for editing audio samples, I wanted to check out Rave anyway. I downloaded it and tried to run it, but it won't start because I don't have the latest versions of the Enhancer Core components. And I can't update those because every time I try to download a newer version with Updater it tells me my account isn't enabled for downloads.

I gather the solution to that is to get in touch with AmigaKit and have them make some database adjustment on their end. I haven't bothered with this previously as I didn't have anything that actually used the Enhancer Core components. Now I do, so I guess I'll have to get on it.
Go to top
Topic | Forum


msteed
Re: Double heigh screen and normal window on
Posted on: 2022/5/22 7:54    #110
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
Topic | Forum


msteed
Re: Double heigh screen and normal window on
Posted on: 2022/5/21 4:11    #111
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
Topic | Forum


msteed
Re: MineCraft (MineTest) work in progress help need it
Posted on: 2022/5/14 7:35    #112
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
Topic | Forum


msteed
Re: MineCraft (MineTest) work in progress help need it
Posted on: 2022/5/13 2:28    #113
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
Topic | Forum


msteed
Re: MineCraft (MineTest) work in progress help need it
Posted on: 2022/5/12 2:15    #114
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
Topic | Forum


msteed
Re: MineCraft (MineTest) work in progress help need it
Posted on: 2022/5/11 3:44    #115
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
Topic | Forum


msteed
Re: Show your AmigaOS 4.x computer or Workbench!
Posted on: 2022/5/11 3:11    #116
Just popping in
Just popping in
@trixie

Hey, E-mu! I applied for a job there once, way back when.
Go to top
Topic | Forum


msteed
Re: SnoopDos causes a DSI error
Posted on: 2022/4/29 6:47    #117
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
Topic | Forum


msteed
Re: Internet speed test that works in Odyssey?
Posted on: 2022/4/16 4:20    #118
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
Topic | Forum


msteed
Re: Bug in Newlib Header?
Posted on: 2022/3/31 0:15    #119
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
Topic | Forum


msteed
Bug in Newlib Header?
Posted on: 2022/3/30 7:49    #120
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.c: In function 'openbsd_reallocarray':
openbsd-reallocarray.c:25:19: error: 'ULONG_MAX' undeclared (first use in this function)
      nmemb > 0 && SIZE_MAX / nmemb < size) {
                   ^~~~~~~~
openbsd-reallocarray.c:25:19: note: '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
Topic | Forum



TopTop
« 1 ... 3 4 5 (6) 7 8 »



[Advanced Search]


Powered by XOOPS 2.0 © 2001-2023 The XOOPS Project