BeBits - LibPak - Talkback

BeBits

LibPak

Talkback

Go back to the LibPak page

Post a new Talkback comment!

re: JPEG Translator problem R5.0.3 too...

By ahwayakchih - Posted on September 30, 2003 - 10:23:36 (#8966)
Current version when comment was posted: 1.2

Yes, i know. It's problem with conflicting library from Becasso. You can use different jpeg translator or (but i don't know if it will wok, probably will work only when You will run translator directly - just like any other application) copy Becasso's jpeg library to "lib" subfolder of translator's folder (/boot/home/config/add-ons/Translators) .
Sorry i can't help more about that now :(
I already started mailing to Becasso authors, so maybe we will find way out of this problem.

JPEG Translator problem R5.0.3 too...

By fatrat - Posted on September 30, 2003 - 03:48:12 (#8964)
Current version when comment was posted: 1.2

I'm using plain out of the box BeOS R5, no Bone or anything else fancy, and upon installing LibPak I was also pelted with translator errors; ended up regressing to the translator I was using before but keeping everything else (so smart to automatically make that backup, thanks!)

Definately a problem that needs to be fixed!

-Jon

re: Will try

By ahwayakchih - Posted on September 2, 2003 - 10:22:55 (#8651)
Current version when comment was posted: 1.2

The problem is not strictly translator's fault. It's just that translator was build using "different" library (IMHO translators should have libraries compiled in - not depend on dynamic libraries, except system ones, but not all developers think that way).
I don't include translators because LibPak is not a place for them. The same way i don't include any other applications that depend on libraries - LibPak would be really huge if i started include any application/translator/whatever depending on libs contained in LibPak (not to mention it would be impossible to include some of them, because of licenses).

By MoerBoer - Posted on September 2, 2003 - 09:38:44 (#8650)
Current version when comment was posted: 1.2

Ok, I'll try that.

Just a question, if the problem is with the jpegtranslator and your version works, why not include that in the libpak?

re: Same problem

By ahwayakchih - Posted on September 2, 2003 - 09:09:55 (#8649)
Current version when comment was posted: 1.2

I didn't change anything in libjpeg so i guess "problem" is still there. Most probably, to remove it i would have to remove "lossless encoding" patch from libjpeg, which will remove functionality - which i would like not to do.
Please can You try JPEGTranslator from OpenBeOS (or the one i posted here)?

Same Problem

By MoerBoer - Posted on September 2, 2003 - 08:48:53 (#8647)
Current version when comment was posted: 1.2

Even with the new lib pak, I also get the jpeg translator error. I'm also running bone on max 2.1. But I think the problem is actually on the installation of max when it asks which jpeg translator you wish to use, I used the 1.3 version I think. I haven't re-loaded the installation to test my theory.

Please look into this, my jpeg files don't want to open anymore.

Thanks,

Emile

By aphex - Posted on September 1, 2003 - 16:18:24 (#8645)
Current version when comment was posted: 1.2

Great collection! The only library I'm missing is libpython.

re: (5) JPEG parameter struct mismatch

By ahwayakchih - Posted on August 6, 2003 - 07:55:33 (#8442)
Current version when comment was posted: 1.1

have You tried removing (just move to anodther directory) "/boot/home/config/add-ons/Translators/JPEGtranslator"?

re: (4) JPEG parameter struct mismatch

By ryanknapper - Posted on August 6, 2003 - 03:10:56 (#8439)
Current version when comment was posted: 1.1

I deleted _all_ libjpeg* and reinstalled LibPak. The same error remains.

re: (3) JPEG parameter struct mismatch

By ahwayakchih - Posted on August 5, 2003 - 21:36:11 (#8438)
Current version when comment was posted: 1.1

Hmm.. so it looks like it's Becasso's fault, or to be more exact: it may be problem with their JPEGTranslator (i always had problems with their GIF translator). I can't help much in this case. You can try to remove their libjpeg links and keep libjpeg from LibPak (which is standard libjpeg 6b + patch to support another encoding - all "official" and working but that patch may be a reason of difference), if error will still happen, try to remove (just moving to different directory will do) their JPEGtranslator. From now on errors should disappear. "default" jpegtranslator from r5 works here, and i have libpak installed, but default translator most probably has libjpeg compiled in. Looks like Becasso's translator uses dynamic library, and probably LibPak puts libjpeg.so in place of link named the same way, and pointing to Becasso's libjpeg.
BTW I don't know what feautures Becasso's translator has (i haven't tried latest becasso) but You may try my jpegtranslator available on bebits (it has lib compiled in, so even if libjpeg changes completly or will be removed, translator will be ok :).

re: (2) JPEG parameter struct mismatch

By ryanknapper - Posted on August 5, 2003 - 19:36:45 (#8437)
Current version when comment was posted: 1.1

Yes, I'm running BONE.
I have "libjpeg.so" and two symlinks ending in ".so.62" and ".so.62.0.0", both of which link to "libjpeg.so.62.0.0" in Becasso's lib folder.
If I remove all libjpeg.so* files I don't get the error any longer. If I put back the latest LibPak file it happens again.

Thx

By BePage - Posted on August 5, 2003 - 13:42:36 (#8434)
Current version when comment was posted: 1.1

Hi,

nice idea too, thanks. Keep up great work!

--BePage

re: JPEG parameter struct mismatch

By ahwayakchih - Posted on August 5, 2003 - 07:40:17 (#8433)
Current version when comment was posted: 1.1

that's strange. it works here ok (i always test whole installation before posting). Do You use Dano? because i got report from another person about that. He found that:
"I resolved this problem by going into home/config/lib and changing
libjpeg.so.62 back to libjpeg.so I guess I just restored the old library."
I have no idea why it was named libjpeg.so.62 (if i understood him correctly). Can You check that name?

re: Request

By ahwayakchih - Posted on August 5, 2003 - 07:33:30 (#8432)
Current version when comment was posted: 1.1

why do You need static libraries? whole thing about LibPak is to not use static libs, only shared.

re: Keep updates

By ahwayakchih - Posted on August 5, 2003 - 07:32:27 (#8431)
Current version when comment was posted: 1.1

You can download changed libraries from LibPak's site. Next time i'll write what libraries were updated since last version, so You'll know what to download.

JPEG parameter struct mismatch

By ryanknapper - Posted on August 5, 2003 - 06:37:54 (#8429)
Current version when comment was posted: 1.1

After installing the latest version of the LibPak, I am greeted by the following error whenever I wish to look at a JPEG file (including at startup when loading my four wallpapers). After hitting OK the image will appear normally.
JPEG parameter struct mismatch: library thinks size is 460, caller expects 464

By hardedged - Posted on August 5, 2003 - 04:08:16 (#8427)
Current version when comment was posted: 1.1

static libs for developer version.
tyia

-edge

Keep updates

By BePage - Posted on August 5, 2003 - 02:53:52 (#8425)
Current version when comment was posted: 1.1

Hi,

please keep the updates. I just have dial-up (56k) and it's a pain to download the hole thing. A nice version numbering (1.0, 1.1, 1.2, ...) would be nice too.

--BePage

re: why not add

By ahwayakchih - Posted on August 4, 2003 - 21:39:20 (#8423)
Current version when comment was posted: 1.1

Sorry for such long time before answer, but i had to think about it, and talk with others (Monni, Jack Burton and ToddB - they were on BeShare at that time :) before making decision.
Short answer is: no (at least for now).
There are few reasons for that:
1. It's license is commercial - Marco (liblayout author) would have to agree for me to include his lib.
2. It's not "standard" - IMHO creating new APIs is not a good thing, because developers community fragments (well it's a shorter version of explanation :). I agree that BeAPI lacks in many areas, but now we have a chance to "patch" it with OBOS (and it would be great if Marco could help with that, as he already has more experience).
3. IMHO if developer wants/needs to override standard API, best is to put it in application's source, so no additional dependencies will be created. But in this case it's impossible (Marco wanted to share his work with others, but without loosing control over code).
4. liblayout is purely BeOS thing. For now all libraries in LibPak are multiplatform (LibPak started mainly because i wanted to port some games and applications). Monni suggested to make "optional" package. That could be a way out:
- it misses the point to make it for only one library,
- 2 additional packages would have to be created (for users and for devs) - and i noticed many people were confused by amount of available versions here (libpak for users, devs, update for users, devs, beta2 to 1.0 for users, devs). I would like to keep it as simple as possible (2 packages), users shouldn't need to know about kinds of libraries, which is for what, etc.. it should just work.

Why not add

By xfilecsm - Posted on July 15, 2003 - 23:03:07 (#8186)
Current version when comment was posted: 1.0

liblayout.so? I don't know how often it is updated, but it would be nice to have in this package.

re: sikosis

By ahwayakchih - Posted on July 11, 2003 - 20:14:05 (#8130)
Current version when comment was posted: 1.0

THX :)
was second "yes" for "want to help?"?

By sikosis - Posted on July 1, 2003 - 10:18:46 (#7972)
Current version when comment was posted: beta2

"Please, let me know if You like the idea, or not (and why). I think we need good dynamic libraries update mechanism for BeOS, and i want to try to create one. If You want to help, let me know :)"

Yes and Yes.

re: Add new lib

By ahwayakchih - Posted on June 29, 2003 - 20:12:54 (#7960)
Current version when comment was posted: beta2

Add new lib

By mar.mack - Posted on March 17, 2003 - 20:02:16 (#6428)
Current version when comment was posted: beta

Could you add this lib please?
http://www.bebits.com/app/2917

Thanks :)

re: Here's a thought (danio)

By ahwayakchih - Posted on March 7, 2003 - 14:20:41 (#6237)
Current version when comment was posted: beta

"It sounds like you are writing an installer that all applications should use: is this correct? "

No, i'm writing instaler app, which devs can use if they want (the same way they can use pkg creator now).

" If not then how is the link from app/lib to /boot/home/config/lib/LibPak/X/ made? Manually by the user or by the libpak installer application? "

If developer will not tell installer (at the creation time) to make such link (or any other to any other file, for example: link "App Readme" on dekstop to app/README.txt"), than user will have to make such link (manually for now, with easy to use manager later) if he/she didn't make libpak default for all software (in that case there are links to libpak in ~/config/lib and no additional links are needed).

"Please do not get annoyed/disheartened by peoples criticisms: it is the way that problems will get resolved before they become ingrained in the structure."
I'll try :)

re: Here's a thought

By danio - Posted on March 7, 2003 - 13:23:52 (#6236)
Current version when comment was posted: beta

I think there is some confusion now.

M: "So it *does* have to be libPak aware!"
"The installer I was talking about is the application-installer, not the libPak-installer."

S: Me too. I'm working on installer application, and it will be opensource - if You don't want to check for missing libraries on libpak's site than You will can just cut out some code :)

It sounds like you are writing an installer that all applications should use: is this correct?

If not then how is the link from app/lib to /boot/home/config/lib/LibPak/X/ made? Manually by the user or by the libpak installer application?

Please do not get annoyed/disheartened by peoples criticisms: it is the way that problems will get resolved before they become ingrained in the structure.

re: Here's a thought

By ahwayakchih - Posted on March 7, 2003 - 10:39:07 (#6234)
Current version when comment was posted: beta

"So it *does* have to be libPak aware!"
"The installer I was talking about is the application-installer, not the libPak-installer."
Me too. I'm working on installer application, and it will be opensource - if You don't want to check for missing libraries on libpak's site than You will can just cut out some code :)

"*application* developers shouldn't have to do anything."
And they don't have to as i said before.

"*library* developers don't *have* to support libPak, if libPak keeps libraries in standard locations, i.e. ~/config/lib"
?? Who said they have to support libPak at all?? Library devs write library, libpak takes care of it if needed.

" Any other location is a bad choice. "
but they are in subfolder of ~/config/lib, not some completly new location. i know it's not a standard, but without ANY official support we also don't have ANY updated libraries, and often there are many "forks" of the same software on bebits. i don't want to overwrite libs, especially if i'm not official person, and i'm alone (if there was a team behind libpak it would have stronger position and could try to make it official).

Updating libs is not a problem at all.

If You think You can create better solution - please create one, and i'll transfer LibPak to You (to stop "forks" and confusing users :)
Or You can join, take care of part of the libs and help creating updater (since You have more knowledge in that area than me).

I started this with hope that some devs will join and help me, but it looks like they can only complain :(

re: here's a thought

By marcone - Posted on March 7, 2003 - 04:24:38 (#6230)
Current version when comment was posted: beta

"Installer doesn't have to be libpak aware"
and then:
"in case of missing lib it will have an option to check on libpak's site".

So it *does* have to be libPak aware!

"Installer will be opensource"

The installer I was talking about is the application-installer, not the libPak-installer. The "Neat-O-Game"-installer for my neat new game has little to do with the libPak installer, but, it *will* have to be aware of libPak if it wants to make use of its nonstandard library locations, or check the libPak website. That's what I meant.

"I want to keep official names, because not all developers will want to support libpak"

Two things: *application* developers shouldn't have to do anything. I.e. they should never have to deal with libraries being in a nonstandard location.
*library* developers don't *have* to support libPak, if libPak keeps libraries in standard locations, i.e. ~/config/lib. libPak could instead be a meta-updater, that knows about a whole bunch of libraries, knows where to find the latest version for each of them, and can download and install those updates itself. Ideally though, library-developers would eventually support libPak and provide update-scripts for their libraries that can be added to the meta-installer on the fly.

"I choose libpak subdirectory because i didn't want to fight with others. I wanted to create peacefull way"

We're talking about two issues here: the first one is the library-updating mechanism, i.e. how do you retrieve and install updates. The second one, and completely unrelated to the first one, is where to store libraries.
IMO, the second issue should not even be considered at all. Libraries either go into an application-specific folder, or info the systemwide config/lib folder. Any other location is a bad choice.
That leaves only the first issue to be solved, and it can be fairly easily solved with an updater that knows where to find updates for libraries.

re: here's a thought

By ahwayakchih - Posted on March 6, 2003 - 09:31:12 (#6220)
Current version when comment was posted: beta

Installer doesn't have to be "libpak aware" - it will look for libraries installed on BeOS. The only thing with libpak will be that in case of missing lib it will have an option to check on libpak's site.
Installer will be opensource so You'll can always modify it for Your needs.

I agree that incompatible libraries should have changed name, but it's up to library developers not me (for example freetype was lib_ttf and with v2 it's libfreetype). I want to keep official names, because not all developers will want to support libpak.

I choose libpak subdirectory because i didn't want to fight with others. I wanted to create "peacefull" way :) And since i'm not "official" person, or anything similar, there's no chance to make all devs support libpak. I asked few ppl with bigger "power" for help and "official support" but they weren't interested :(
If You'll gather more popular developers and "official" persons of BeOS community and get support for libpak, i'll change it to install to /boot/home/config/lib, otherwise i don't want to have any fights with incompatible releases and confuse users (thx to libpak subfolder there will be no incompatibilities and even if devs will not support devpak, user still can create link in a second).

re: here's a thought

By marcone - Posted on March 6, 2003 - 00:32:55 (#6213)
Current version when comment was posted: beta

"You don't have to change applications at all".

When I said "application", think of the entire package, including the installer. The installer would have to be libPak-aware, and know to put the links in place.

"In fact You would have to recompile them for using new (non standard) library name"

The renaming I spoke is purely on the library side, and only when breaking compatibility. Obviously in that case you would either NOT change the app (and thus keep using the old library), or adapt your application to use the new library with the new name, and recompile. For example, if I were to create an updated, incompatible version of liblayout, I would likely call it "liblayout2.so". Old applications would continue to use the old liblayout.so, while newer applications would be developed for and linked against liblayout2.so

There really is no reason to put all the libraries under 'libPak'. Really.

Sorry, didn't notice the developer version..

By toddb - Posted on March 5, 2003 - 07:32:49 (#6197)
Current version when comment was posted: beta

silly me... 8-P

By toddb - Posted on March 5, 2003 - 07:30:24 (#6196)
Current version when comment was posted: beta

Could you please include the headers, they don't take up much space, and I actually use a lot of these libs, and find it to be a royal pain to have to go and find the libs and either recompile myself, or find headers for version of libs I have installed.. Thanx

re: here's a thought

By ahwayakchih - Posted on March 5, 2003 - 00:29:46 (#6192)
Current version when comment was posted: beta

You don't have to change applications at all. In fact You would have to recompile them for using new (non standard) library name, because on BeOS lib renaming is not used (well.. Installer could change binaries link table to current libpak, but that wouldn't be safe)
With folder trick You don't have to change any application, just put a proper link.
Another way is to add libpak path to BELIBRARIES and LIBRARY_PATH environmental variables. I didn't used that because i don't want to mess with user system.

I'll build a site for libpak, where there will be option to download whole libpak or just chosen libs. Also Installer i'm writing will check for them when system will not have needed ones.
LibPak "manager" will have updating option of course, and i'll look at Your updater :)

here's a thought...

By marcone - Posted on March 4, 2003 - 22:23:06 (#6190)
Current version when comment was posted: beta

Instead of having config/lib/libPak/..., just put every library in config/lib like you're supposed to.
Then, write an updater app that uses my network updater (http://www.bebits.com/app/2834) to update the various libraries as needed/available. Compatibility between versions should be handled by the libraries themselves, i.e. if a new version is incompatible with an old one, it should get a new name.
The advantage of the above method is that users can update individual libraries without having to download a whole libPak again, and applications don't have to be changed to explicitly support libPak and its nonstandard library locations.

re: Versioning issues

By ahwayakchih - Posted on March 4, 2003 - 14:54:35 (#6185)
Current version when comment was posted: beta

There will be LibPak/2 only when some lib will break compatibility. Lib's versions doesn't matter in that case.
You will not have to go through all old app's dirs and change links because:
- they will still work with v1
- i want to write "manager" for that, which will scan for You (but of course You will have to accept change, in case some app will not wok with newer lib).

it is possible to just name libs with version number but i don't think it's good because when You have newer version You have to put link named as old version. so for example if application was linked to libSDL.1.2.4.so You'll have to have link named like that and change it to point to newer lib each time. that is not as bad, but if You have app linked to 1.2.3 and another to 1.2.5 You have to have 3 links for one lib (plus 4th named libSDL.so because all apps on BeOS were linked that way). that will create a mess and confuse users.
i thought that trick with folder links is a cleaner way.

there is no standard way for versioning apps and libs. each developer/team choses they're way (and sometimes they still version different way each time).
i think major number should change each time ABI changes, than maybe apps should link to "libSDL1.so" "libSDL2.so" etc.. that would help to check if app works with lib or not. But it's not a BeOS way, so all devs would have to start to support that which is unreal.

i'm trying to write installer app now, and i found a lib with which i can check which libs binary needs. i'll look for the way to check if lib contains needed functions also. that would make life easier for all of us :)
If someone knows if there is a way to check if function A is the same as the one needed by application please let me know (i know how to get names of functions, but not how to check if they are really the same, ie: the same arguments, the same return type etc..)

Versioning issues

By danio - Posted on March 4, 2003 - 13:36:47 (#6184)
Current version when comment was posted: beta

I think this is a good idea but am not clear on how the versioning is going to work.
Say libsdl 1.2.4 is in LibPak/1.
Then I get an app that needs libsdl 1.3. So The new LibPak will have libsdl 1.3 in LibPak/2?
And now I have to go through all the old apps and make links to LibPak/2 if they can handle it or leave links to LibPak/1 if they can't?
So each application developer is responsible for putting the links to the correct path?
If that is so I think the LibPak directory names need to be more clear, e.g. LibPak/1.2.4 otherwise it is a hassle for developers to work out which directory to link to.

Is it possible to do this with the lib filenames instead like Unix (e.g. Irix)?
So you have libSDL.1.2.4.so and libSDL.1.3.so on the machine and the application developers have to link their app against the correct version when they build it.

Is there a standard for the version numbers of libraries - what number is changed in the version to indicate interface incompatibility with a previous version?

Jace - If you think each app should have libs in its own directory why not just compile the lib into the application? This is effectively what you suggest.

THX

By ahwayakchih - Posted on March 3, 2003 - 22:05:49 (#6172)
Current version when comment was posted: beta

For good words :)
I'll try to keep them up to date, i'm going to write updater app later (and good installer app - it's in works, but i wanted to release libs because some other apps i compile needs them).
But i don't know how much libs i can handle alone, i mean it takes time and i don't want to drop other projects, so it would be good if some devs could help me.
Jace: You don't have to kopy them, that's why i install them in subflder of global lib folder - other (older) apps will not brake after that. Also this project is for keeping track of versions for You ;]
And if You really really don't want to install them in /boot/home/config/lib/LibPak/1/ put them in some other folder You want and put "lib" link to it in app's folder instead of duplicating them (which completly looses shared libs idea IMHO).

Shared libs are good, just has to be used properly (like any other tool in the world). f You hate them so much look into /boot/beos/system/lib folder - our beloved BeOS uses them all the time :)

Good idea, But...

By Jace - Posted on March 3, 2003 - 21:14:21 (#6171)
Current version when comment was posted: beta

I only install libs into a lib folder within the app folder of the app that needs the lib. I don't install any libs globally. This is to avoid keeping track of versions and what's installed, etc. I hate shared libs, actually, and wish they'd stop existing... ;-) ;-P

Good idea, though!

By BePage - Posted on March 2, 2003 - 17:46:25 (#6147)
Current version when comment was posted: beta

Really great idea!! Only need it has always be up-to-date!

--BePage

thanks god somebody thought about this

By IgRussell - Posted on March 2, 2003 - 17:22:11 (#6145)
Current version when comment was posted: beta

Thanks god somebody thoguth about this, very good, thank you. Finding latest libs (and the hope fcor making other apps works wirth them) was already a hell. thanks. By the way, anybody realized that latest SDL libs makes Pixel32 faster, but Tux Typing much slower?.



	Comment Pages: << prev \| 1 \| 2 \| next >>













			Recent Downloads - # 554 Total Downloads - # 245 Total Views - # 186 User Ratings - # 80




			Class Libraries Shared Libraries




			1. BePodder - 9.80 2. QEMU - 9.68 3. ScummVM - 9.57 4. cpu_fix - 9.42 5. Jukebox - 9.40 6. libdl.so - 9.40 7. Haiku AGP busm... - 9.35 8. vim6 - 9.31 9. Beezer - 9.26 10. HandBrake - 9.25




			1. BeOS 5 Perso... - 13,656 2. Realtek RTL8... - 13,142 3. Ati Radeon G... - 12,641 4. Ensoniq Audio... - 7,598 5. ATI Rage 128... - 7,466 6. USB Joystick... - 5,685 7. Broadcom 440x... - 5,432 8. S3 Trio 64 v2... - 4,752 9. USB Serial dr... - 4,721 10. Intel Extreme... - 4,483




			You are not logged in. Login


	Unless otherwise noted, everything is copyright © 1999-2009 Haikuware. All Rights Reserved. For more legal trivia, take a gander at our Legal Stuff page and our Privacy Statement.