• Welcome to OS2World OLD-STATIC-BACKUP Forum.
 

News:

This is an old OS2World backup forum for reference only. IT IS READ ONLY!!!

If you need help with OS/2 - eComStation visit http://www.os2world.com/forum

Main Menu
Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - eville_hn

#1
Thanks for reporting the issue with the dependency to TCPIP32 (also via PM).

I think I meanwhile found why it is now there. The library I included for the new RAW support does use some network byte order conversion functions (htons/ntohs, htonl/ntohl). Obviously I have overseen this when porting it to OS/2 for GBM. Usage of the functions/macros is pretty common in code developed for Unix/Linux. I'll see if I can replace them by GBM own implementations to get rid of the dependencies so that GBM will also work on Warp 3 again (although nobody complained yet).

Nevertheless with Warp 4 it is a good idea to go to 32bit TCP/IP stack alone for security and better performance. eCS user have it on-board from the beginning.

Only GBM version 1.70 and 1.71 are affected by the TCPIP32 dependency, older versions should be fine.

EDIT:
A patched GBM.DLL 1.71 for Warp 3/4 with 16bit TCPIP stack is now available from the GBM website. If you have such a system, I'd be interested in success reports ;) . All eCS users and users of Warp 4 with 32bit TCPIP stack can keep the original GBM.DLL. The next official release will have the fix incorporated.
#2
Rexx / Re: ReSize and convert Images
2008.04.05, 00:52:02
Of course, you can use whatever you think is more suitable for you :) .
But there are some things I'd like to add to your notes.

Quote from: RobertM on 2008.04.04, 03:55:37

The advantage(s) of having it in a REXX DLL is:


  • The DLL is faster than the interpreted code

I don't think so because the DLL is basically doing nothing than forwarding parameters.

Quote from: RobertM on 2008.04.04, 03:55:37
  • As you noted, the same DLL can be used to provide added functionality
  • It simplifies the base code, since unlike C, you cannot (easily) have function calls to external REXX functions while maintaining full capabilities

This is not correct. You can have REXX functions externally. Just put the function code into a separate REXX file and call it exactly as the function name. If the function you want to have externally is called imgReSize, simply name the file imgResize.cmd and put the code into it but skip the function declaration and use exit() instead of return. The REXX interpreter will automatically call the the function when it is not found in the active REXX file. Have a look at the attached example. The package contains both variants.

Quote from: RobertM on 2008.04.04, 03:55:37
  • Since GBM is being regularly updated, it means that, with no revisions to the REXX code for new formats, simply replacing the DLL with the newest version "updates" the REXX program's capabilities (for instance, being able to determine image sizes of new or variant image formats)

In principle this is correct but in the special case that we discuss here it is different. The GBM code for scaling is not part of gbm.dll but part of either gbmrx.dll or jep's dll. This means that if a fix is done for the scaler,both dlls needs to be updated. If the function would be coded in REXX using gbmrx.dll, you would automatically get the fix because gbmrx.dll is always part of the GBM package.

Quote from: RobertM on 2008.04.04, 03:55:37
  • It means that (for instance in my case, where we use a lot of web scripts), one does not have to add a whole section of code to each and every REXX cgi script just to read image information... instead, I would load the DLL once on server startup, and then call the functions in it.

Have a look at the attached example on how this can be done.

Quote from: RobertM on 2008.04.04, 03:55:37
  • It increases cgi performance for more reasons than the fact that a C DLL is faster than interpreted code, such as the simple fact that the web server's cgi engine has a bunch less code to load to execute the same tasks (since the DLL is already loaded into memory, making the DLL call method not need to have a few dozen copies loaded, nor require the web server's cgi engine to reload that section of code for every thread it is running that uses that code)

If the function really has many things to do, you're right. But in this case you won't probably notice any difference. In case you don't know yet, the OS/2 REXX interpreter stores a tokenized version of the program in the extended attributes of the script. Thus running the script again is very fast. This is especially important for  externally located functions.

Quote from: RobertM on 2008.04.04, 03:55:37
Thus to clarify, my point is: each method has enticing reasons why some would prefer them. I personally prefer jep's method as most of the coding I do is either (a) for web cgi (and his method is more compact, faster, and easier to code with) and/or (b) I like writing wrapper functions for various things to simplify calling stuff from anywhere - which I find far easier with functions set up all in one DLL and/or (c) as my web server gets quite a decent amount of traffic, I find that 20 or 50 or 100 lines of extra code does indeed impact performance, disk usage, etc (and I like minimizing disk usage as much as possible since SCSI disk drives are kinda expensive).

Well, if reducing disk accesses is your optimization goal, you should better use a RAM disk or prevent creating temporary files. This is also the big advantage of the gbmrx API design. All transformations on the bitmap can be sequentially done in memory without writing intermediate files.

Quote from: RobertM on 2008.04.04, 03:55:37
For standalone apps that just need to query image parameters, having everything in REXX may be better, easier to implement, and would save memory since the code is only loaded with the app, then can be unloaded when the app exits (unlike my scenario, where the REXX DLL needs to be loaded at server start and NEVER unloaded).

The same mechanism also works with the externally located REXX function. In the attached example (runme_separate.cmd) the dll is loaded and only unloaded at the end of the program.


I hope the examples and the hints are helpful.  :)

eville
#3
Rexx / Re: ReSize and convert Images
2008.04.04, 03:31:14
Hello,

I've read all your discussions about gbmrx (thread Determine Image Size) and to me it looks like having a special dll for operations that could be directly coded in REXX is overkill  ::). It took me about half an hour to hack a function in REXX that does almost the same as your dll. The benefit of having it coded in REXX is that no additional dll is required.

If the resize function is intended only for a one step operation on the same images, it might be OK. But if you plan to run another operation on the resized images afterwards it might be a rather bad idea. Not all output formats are lossless. If you scale a bitmap and write it as JPG image, then read it again for another operation and save it as JPG a second time, the image quality will suffer because JPG is a lossy format, also if quality is set to 100% when saving it!

I have attached the pure REXX version. Maybe some special features are missing but hey, it is REXX, so just add them.

eville