@rjd324

Looks like you've found the reason, which was indeed a multi-assign to C:. Curiously, 'C:' isn't present in the Assign list you posted, which makes it hard to see the problem.

@rjd324

Perhaps C: is multi-assigned, with the path to Python being one of the assignments? Try "Assign" by itself to see what the assignments are.

@tonyw

Quote:
Thanks for the tip. It didn't work- the page still goes blank when I preview the post (when I display the source for the blank page, it's blank too). However, it led me to try something different that did work.

There are two 'Preview' buttons on the post entry page. I've never been clear on what the difference is, but I normally use the lower one, as it seems to give a preview that more closely resembles the final post. That's the one that causes the page to go blank when there's a '<' (or an ampersand lt;).

However, when I tried the upper 'Preview' button the '<' appeared as it should. I tried submitting the post, and the '<' showed up, just as it did when using the upper 'Preview' button. So the problem seems to be limited to the lower 'Preview' button.

Incidentally, there's no problem when using the lower 'Preview' button with this post, so the problem isn't due just to the '<', but to the entire line of PostScript code in that particular post.

@Deniil

Are you sure that's where the message is coming from? Both ListDynDep and readelf -d indicate that AK-8SVX.datatype has no dynamic section, and therefore does not require any shared objects.

Double-clicking a datatype's icon normally runs "C:AddDataTypes", which adds the associated datatype to the system. But I notice that the default tool for the AK-8SVX icon is "MultiViewer:MultiViewer", which isn't really what you want (though MultiViewer doesn't use any shared objects, either).

Perhaps your default tool somehow got set to some other program?

@Raziel

Quote:
I added the following at the top of the file, just after '%%BeginProlog':


'/Duplex true' enables duplexing. Setting it to false instead disables duplexing, useful if you want to print something single sided and your printer is set to duplex by default.

'/Tumble false' sets the printer to flip the printed pages along the long side, book-style. Setting it to true instead tells the printer to flip the pages along the short side, calendar-style. False seems to be the default setting, at least on my printer, as even files sent directly to LPR: come out flipped on the long side.

It would be nice if a future version of the PrinterPS preferences editor (Enhancer?) had the ability to adjust these settings, and even nicer if the PostScript printer driver knew about duplexing. As it currently stands, you need to manually edit the postscript_init.ps file to change the settings. Fortunately these settings work for me 99% of the time.

Edit: Altered PostScript clip to have proper '<<' in it.

@livebyfaith74

I use LPR: with my networked HP laser printer. I tried a number of different network printer drivers when I first got the printer, and LPR: seemed to work the best (and it's OS4 native, unlike some of the others).

For programs that can generate PostScript output natively (like AmiPDF) I just send the PostScript directly to LPR:. For programs that don't generate PostScript on their own I use the Amiga PostScript printer driver, which is set to send its output to LPR:. (The PostScript driver has a passthrough mode that can send PostScript directly to the printer, but it's easier to just send straight to LPR:.)

My printer has a duplexer that can print on both sides of the page. The Amiga printing system doesn't know about duplexing, so I added a line to the postscript_init.ps file that the PostScript printer driver uses to enable (or, if I edit it, to disable) duplexing. That only works when using the PostScript driver, so I also set the printer to duplex by default, which works when sending PostScript directly to LPR:.

@joerg

Quote:
Thanks for this valuable bit of information. Media Toolbox has no popup help, so there's no indication what the 'Last ID' control does. Given that information, I can guess what the 'Last LUN' control does. But what about 'Last TID'?

Quote:
Indeed he did- thanks!

When I try to search for anything (using Odyssey or IBrowse) I get the following:

Quote:
I tried logging in, though search has always worked even if not logged in in the past, but I get the same error.

Quote:
I've no access to the sources, but according to the wiki:

Quote:
And:

Quote:

@daveyw

Perhaps you could try opening the file, on the assumption that any file that is actively being written is going to have an exclusive lock on it, so opening it will fail. If the open succeeds, the file must have been closed and the lock released. If using a DOS script, you could use any DOS command that opens a file and does something harmless if it succeeds (i.e. CountLines).

@AmigaOldskooler

Thanks for another great writeup. I feel like releasing something new just so I can see my name in one of them!

I say that only partly in jest; when you're developing just for personal enjoyment, getting some recognition from the community can be a significant motivation. Keep up the good work; you don't have to be a developer to help support Amiga software development!

@joerg

A great little utility- thanks!

@all

It's obvious what most of the displayed numbers represent, but there are some whose meaning is not apparent. Does anyone know what the F:xxxxx, D:xxxxx, and S:xxxxx figures at the top of the display mean? (See Capehill's screenshot for reference.)

@trixie

I always enjoy reading your blog entries. You write very well, particularly for someone who is (I presume) not a native English speaker.

Quote:
Indeed it did. And while in retrospect, once you learn that AllocBitMap() and AllocBitMapTags/TagList() work differently from each other you can reason out why that is, I agree with FlynnTheAvatar that based on reading the autodocs that's not what you'd expect to happen.

It would be nice if the autodoc for AllocBitMap() could be updated to add a note that due to the need for backwards compatibility, you might not get an optimal BitMap for an RTG display even if you pass an RTG friend BitMap. Otherwise this is sure to catch someone else by surprise someday.

@FlynnTheAvatar

Quote:
I don't have any inside knowledge of how graphics.library works, so I can only make educated guesses as to what might be going on, based on the results you're seeing.

I suspect that as an OS 3.0 function, AllocBitMap() has to be backwards compatible in order to allow old OS3 programs to run, even when passed a friend BitMap. While as an OS 4.1 function, AllocBitMapTags/TagList() is free to assume a more modern program is calling it, on a more modern machine. So even when passing the same parameters, you might be getting a different BitMap depending on which function you call.

I imagine you're running the example program on a 32-bit truecolor Workbench screen, which means your friend BitMap is also 32-bit truecolor. But the backBuffer BitMap you're allocating has a depth of only one bit. So the question is, what happens when you ask for a one-bit color-mapped BitMap, but pass a 32-bit truecolor friend BitMap?

Back in the OS 3.1 days even graphics cards typically supported planar displays when the depth was less than eight. So for compatibility with programs from that era, you may well be getting a one-plane planar BitMap from AllocBitMap(). Of course that's going to require planar to chunky conversion when blitted to a 32-bit BitMap, which is going to be slow.

When calling AllocBitMapTags/TagList() I wonder if you're not getting something like an 8-bit color-mapped BitMap instead. It would use eight times as much memory (not as big an issue on an OS4 system), but would be much faster to blit to a truecolor BitMap.

As Capehill suggested, it might be instructive to query the BitMaps returned by the two different functions using GetBitMapAttr() to see how they compare.

BTW: I don't think it makes any difference with this issue, but the backBuffer BitMap doesn't really need to be BMF_DISPLAYABLE, since it is never displayed directly, but is always blitted to a displayable BitMap for display.

@afxgroup

Quote:
What about https://www.researchgate.net/publicati ... ith_compiler_optimization? The other two sites work with IBrowse too, while this one doesn't.

@afxgroup

Quote:
I don't think it's an SSL problem- that's not the kind of security issue that Cloudflare is looking for. They're looking for automated web bots that are probing or potentially attacking a web site. Simply checking SSL certificates and looking at user agents isn't good enough, as robots also use SSL, and know how to spoof as being an actual web browser.

I'm sure the details of how they attempt to discriminate between bots and real users are proprietary, but it seems to involve running some Javascript (no doubt heavily obfuscated) on the browser, and if they're still not sure, putting up a CAPTCHA.

Quote:
No, it's an Odyssey problem. Most likely the Javascript makes use of some Javascript or browser functionality that Odyssey doesn't support, so the test fails or doesn't even run. It never gets as far as putting up the CAPTCHA, though in the past when the CAPTCHA did appear it didn't help- though the CAPTCHA itself seemed to work, clicking 'Verify' at the end just brought up another CAPTCHA, and you still couldn't access the site or page.

Regardless of the cause, the effect is the same- Cloudflare threat protection on a site means you can't access it with Odyssey. The situation with IBrowse seems a little more complex.

@Futaura

Quote:
This link that LiveForIt posted over on the RadeonHD V.5 driver thread is an example of a web page that is not accessible to Odyssey because of Cloudflare's threat protection:

https://www.researchgate.net/publicati ... ith_compiler_optimization

There's no CAPTCHA with this page, so either there are different versions of the threat detection code, or the code has changed and no longer gets far enough to even bring up the CAPTCHA.

When I try to follow the link with Odyssey, I get a page with a "Checking if the site connection is secure" message, followed by a high CPU load as a lot of Javascript runs. After a bit the message "This check is taking longer than expected" pops up. After a bit more the page reloads, and the whole thing repeats.

Every now and then, for whatever reason, I instead get a "Verify you are human" button in addition to the "This check is taking longer than expected" message. With other sites in the past clicking on such a button has brought up the CAPTCHA, but here it has no effect, and eventually the page reloads again.

When I try this same link with IBrowse I get the same "Checking if the site connection is secure" page, but there doesn't seem to be any Javascript executing, and nothing further happens (no "taking longer" message or page reloading).

Here's another link that doesn't work with Odyssey due to Cloudflare:

www.bhphotovideo.com

When I try it with Odyssey, I get the same result as with the link above. But curiously, when I try it with IBrowse it works fine (or as well as it can, with no CSS support).

@Futaura

I was thinking more of the threat protection aspect of Cloudflare- almost every time I encounter a website that wants me to prove I'm not a robot and then won't let me in no matter how many times I complete the CAPTCHA, it turns out to be Cloudflare. So I've come to associate Cloudflare with "can't go there with Odyssey." I imagine IBrowse also has this problem, though I've never actually tried it.

If that part of Cloudflare can be separated from the SSL/certificates part, then of course I have no objection to that.