sell stationery
Dear Sir or Madam: Having obtained your name and address from http://www.prideproducts.com that you are a large buyer of stationery. As article of this kind fall within the scope of our business ivities, we take this opportunity to express our wish to enter into business relations with you and enclose our illustrated catalogue & the detailed price-list for you reference. We hope to hear from you soon. Yours faithfully Liu Ming Company Profile As a network-structured company, we have three main Lighting firms and three Stationery ones. The product series include:Road lamps,Medium pole lamps,High pole lamps,Garden lamps,Lampion,Lawn lamps,Flood light,Earth-huried lamps,Tunnel lamps,Worklight,Halogen lights,Advertising lighting,Street lighting,Ceiling lighting,Hideman lighting,Under water lighting,European lamps,Metal Halogen Lamp,Bunker light,Lantern lamp,Lamp with motion sensor,Metal halide,Portable lamp,Stemp light,Lantern lamp,Sodium lamp,Mercury lamp,Corner light,Project light,Pit lamp,Bulb,Flash light,Articles for daily use,Glue,Water colour paints,Modeling Clay,Chalk,Ballpointfluorescence pen,Filing cabinet,File-keeper,Stapler,Paper cutter,Pencil sharpener,Cutter knife,Students Stationery,Packing Tape Dispenser and other various kinds of stationery. In addition, we are in a position to produce and process metals, rubber, plastics, clothing and so on. There are also m outdoor Exciter ore than 100cooperative companies that produce stationery and illumination. Business Scope: Stationery Lamps Rubble&Plastic Products electronics Processing Products (not containing dangerous chemicals and chemicals easily causing poison) Textiles Clothing Hardware Retail and wholesale of all kinds of daily necessities etc Sincerely welcome customers from home and abroad! At the same time, we provide a wide field for those who want to be successful in business,and we warmly welcome the organize and individual to have acorporation both of home and abroad. Company name: Ninghai Solar River Lighting Co,.Ltd Company code: 74215665-3 Company nature: Limited liability company Legal representative: Hu Shangui Address: No.2 YINHE Road, Ninghai, ZheJiang Registration office: by Ningbo Industrial and Commercial Administration Bureau, Ninghai Branch Province: ZheJiang City: Ninghai Ningbo Tel:86-574-65206317 Post code: 315600 Fax: 65206317 e-mail: [EMAIL PROTECTED] http://www.tayanghe.com http://tayanghe.cn.alibaba.com http://www.alibaba.com/bin/hermes/individual/aboutus/cntayanghe.html ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
sell stationery
Dear Sir or Madam: Having obtained your name and address from http://www.prideproducts.com that you are a large buyer of stationery. As article of this kind fall within the scope of our business ivities, we take this opportunity to express our wish to enter into business relations with you and enclose our illustrated catalogue & the detailed price-list for you reference. We hope to hear from you soon. Yours faithfully Liu Ming Company Profile As a network-structured company, we have three main Lighting firms and three Stationery ones. The product series include:Road lamps,Medium pole lamps,High pole lamps,Garden lamps,Lampion,Lawn lamps,Flood light,Earth-huried lamps,Tunnel lamps,Worklight,Halogen lights,Advertising lighting,Street lighting,Ceiling lighting,Hideman lighting,Under water lighting,European lamps,Metal Halogen Lamp,Bunker light,Lantern lamp,Lamp with motion sensor,Metal halide,Portable lamp,Stemp light,Lantern lamp,Sodium lamp,Mercury lamp,Corner light,Project light,Pit lamp,Bulb,Flash light,Articles for daily use,Glue,Water colour paints,Modeling Clay,Chalk,Ballpointfluorescence pen,Filing cabinet,File-keeper,Stapler,Paper cutter,Pencil sharpener,Cutter knife,Students Stationery,Packing Tape Dispenser and other various kinds of stationery. In addition, we are in a position to produce and process metals, rubber, plastics, clothing and so on. There are also m outdoor Exciter ore than 100cooperative companies that produce stationery and illumination. Business Scope: Stationery Lamps Rubble&Plastic Products electronics Processing Products (not containing dangerous chemicals and chemicals easily causing poison) Textiles Clothing Hardware Retail and wholesale of all kinds of daily necessities etc Sincerely welcome customers from home and abroad! At the same time, we provide a wide field for those who want to be successful in business,and we warmly welcome the organize and individual to have acorporation both of home and abroad. Company name: Ninghai Solar River Lighting Co,.Ltd Company code: 74215665-3 Company nature: Limited liability company Legal representative: Hu Shangui Address: No.2 YINHE Road, Ninghai, ZheJiang Registration office: by Ningbo Industrial and Commercial Administration Bureau, Ninghai Branch Province: ZheJiang City: Ninghai Ningbo Tel:86-574-65206317 Post code: 315600 Fax: 65206317 e-mail: [EMAIL PROTECTED] http://www.tayanghe.com http://tayanghe.cn.alibaba.com http://www.alibaba.com/bin/hermes/individual/aboutus/cntayanghe.html ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: 0.05
Mark Wielaard <[EMAIL PROTECTED]> writes: > On Mon, 2002-12-16 at 22:36, Brian Jones wrote: > > * Integrate any remaining patches on Savannah as needed. > > I still have some patches "claimed" but I got absorbed in gcc 3.3 > testing and didn't have time to do more merging. I am currently looking > at merging/fixing the ObjectStream classes between Classpath and libgcj > but ran out of time and I probably won't have time the rest of the week > to look after the JRVM patches. So feel free to analyze and/or patch the > remaining items. I haven't gotten to this yet. The gjdoc, dist, and automake crap took me much longer than expected over the past few days. > > * Full javadoc generated by gjdoc available for general consumption. > > There is only one open issue here that I know of. The produced HTML > pages should contain the actual Copyright notice of the java files they > were produced from not just some generic blurb. This is easy to > implement for the GNU Classpath classes since they always have that > statement as the first comment block at the top of the file. In general > it will not be that easy to extract this info from the java source file. Some way of specifying copyright/footer on a per package/class basis would be great... but this appears to be added in the xsltproc step. I've ignored it for now but there is a notice to this affect that you describe on our website. I've just committed a large number of changes to finish bringing gjdoc generation into the build/dist mechanism, fix some broken things like DESTDIR, uninstall, and too many invocations of gen-classlist.sh. I think make distcheck almost works now (fails in distcleancheck), but it's not a big deal either way. Brian -- Brian Jones <[EMAIL PROTECTED]> ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: eclipse status (summary: it looks nice)
On Mon, 2002-12-23 at 16:58, Mark Wielaard wrote: > Very nice. I am using your extended patch now and don't get any out of > memory issues anymore and it feels faster (since it is not trashing all > the time). But I do get lockups now and then (mostly when trying to use > the new project wizard). Do those happen to you? I don't know about lockups, but I do see the monitorexit problem you reported (when I add a new file to a project). Perhaps this is a problem with the hash synchronization code. However, I fear that we'll never be able to reproduce a small example. > Part of this is caused by the fact that the > VMClassLoader keeps tries to load new classes first by first trying to > open the lib-sub-package-class.so files. But since there are no natively > compiled classes it keeps falling back to the interpreter. We must cache > the result of Runtime.(internal)loadLibrary() somewhere. That's a good idea. I also noticed that we create a lot of garbage when loading bytecode from jarfiles. > I had to do this also. The below is the text version of the installation > part of http://www.klomp.org/mark/gij_eclipse/. Ah, yes - I missed that. > Step 4 is the disabling > of the verifier. Is your version of Eclipse based on 2.0.2 or 2.1-M4? 2.0.1 (admittedly, I'm not using our latest development version) AG ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: eclipse status (summary: it looks nice)
Hi, On Mon, 2002-12-23 at 05:07, Anthony Green wrote: > On Sun, 2002-12-22 at 19:32, Anthony Green wrote: > > On Sun, 2002-12-22 at 17:10, Mark Wielaard wrote: > > > There are still some big showstoppers. You will need to disable the > > > Garbage Collecter or you will get the attached exception while starting > > > up. > > > > Try this... > > > > 2002-12-22 Anthony Green <[EMAIL PROTECTED]> > > > > * boehm.cc (_Jv_MarkObj): Mark the protectionDomain of a class. > > Yes, that was it! Very nice. I am using your extended patch now and don't get any out of memory issues anymore and it feels faster (since it is not trashing all the time). But I do get lockups now and then (mostly when trying to use the new project wizard). Do those happen to you? > I'm running Eclipse right now. It's surprisingly usable on my 2.4GHz > P4. Yes, our interpreter isn't that bad and it certainly helps that the core classes are precompiled and that we use a widget library based on native GTK+. It seems that most of the slowness comes from the actual loading of the classes into memory. Part of this is caused by the fact that the VMClassLoader keeps tries to load new classes first by first trying to open the lib-sub-package-class.so files. But since there are no natively compiled classes it keeps falling back to the interpreter. We must cache the result of Runtime.(internal)loadLibrary() somewhere. > In addition to this fix, I had to disable class verification. Perhaps > the version of Eclipse you're running doesn't have the problematic > bytecode sequence my version has (which is a Red Hat-internal version). I had to do this also. The below is the text version of the installation part of http://www.klomp.org/mark/gij_eclipse/. Step 4 is the disabling of the verifier. Is your version of Eclipse based on 2.0.2 or 2.1-M4? Cheers, Mark What do you need If you want to run it yourself you should be familiar with compiling gcj from source (either current mainline or the gcc-3_3-branch) and you will need to apply the following patches. * [3]Patch: platform usleep function. * [4]URLClassLoader fix for getCanonicalFileURL fix. * [5]StringBuffer patch. * Comment out the body of the _Jv_VerifyMethod method in the verify.cc file. These patches (except the verify.cc change) should be applied to CVS soon so you might not need them. When you have build and installed the new GCC you will need to make the following changes to the install. * Go inside the bin directory of the new GCC install and make a java symlink to the gij program. (Eclipse expects a binary called java, you can give the -vm gij option, but then it won't autodetect gcj as Standard VM.) * Copy the share/java/libgcj.jar file to lib/rt.jar. Then create a directory jre/lib/ and make another copy of the rt.jar here. (Note that these cannot be symlinks.) * Make a directory src and copy the gnu, java, javax and org directories from the libjava source directory in it. Then create a src.zip file which contains this src directory. Put this src.zip file in the parent directory of the dir you installed the new GCC in. So if you installed in /usr/local/gcc34/, then put the src.zip in /usr/local/ (This is needed for extra WOW! in the code editing screenshot.) This is all needed because eclipse expects a tradition java environment. It should be easy to hack [6]org/eclipse/jdt/internal/launching/StandardVMType.java to recognize gcj by default. Disable the garbage collector by export GC_DONT_GC=1. If you don't do this eclipse will not startup properly and you will find a stacktrace in the workspace/.metadata/.log file mentioning a InvocationTargetException caused by a NullPointerException. Finally get the [7]latest stable Eclipse build (you want the eclipse-SDK-M4-linux-gtk.zip.) It will create a directory eclipse and comes with all the sources (and a precompiled binary and the classes in jar files). 3. http://gcc.gnu.org/ml/java-patches/2002-q4/msg00469.html 4. http://gcc.gnu.org/ml/java-patches/2002-q4/msg00489.html 5. http://gcc.gnu.org/ml/java-patches/2002-q4/msg00488.html 6. http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.jdt.launching/launching/org/eclipse/jdt/internal/launching/StandardVMType.java?rev=HEAD&content-type=text/java 7. http://download.eclipse.org/downloads/drops/S-M4-200212181304/index.php ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: eclipse status (summary: it looks nice)
On 22 Dec 2002, Anthony Green wrote: > > * boehm.cc (_Jv_MarkObj): Mark the protectionDomain of a class. > > Yes, that was it! Good catch... > IIRC, -fno-assume-compiled=... is working now -- so perhaps we can start > selectively compiling parts of Eclipse to .so files. Not quite. I committed my earlier patches, but there's a separate problem in interface initialization for which I'll propose a fix "soon". Jeff ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Graphics2D using OpenGL ?
Anthony Green wrote: It's a great idea. Here is some evidence: http://www.cs.umd.edu/hcil/agile2d/index.shtml After looking a bit more into it, I think that it will be easier to just start our own implementation. I'm going to look into it. No promises and certainly no timeline. 1) Has anybody here some opengl experience and would like to help with it ? I'm mainly thinking about stuff like opengl versus multiple rendering contextes(sp?), render-to-texture and most important, opengl integration with window system (win32 and X for now) 2) Does anybody _really_ understand java.awt.image ? I'm mainly talking about Raster stuff and color models (implementation, not just idea). 3) I'm really worried about gtk integration. I suppose that making swing to run on top of OpenGL Graphics2D Frame would be easier that really integrating everything inside heavyweight gtk components. I hope that somebody can prove me wrong :) Anyway, this is a sure way to get into pesky portability problems. I would like to get graphics running at least at windows and linux. Artur ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Graphics2D using OpenGL ?
Artur Biesiadowski <[EMAIL PROTECTED]> writes: > Brian Jones wrote: > > As this was a research project and is not intended to be supported or > > developed further and is under the MPL 1.1, is it of any use other > > than a proof of concept? > > > > Even as proof of concept it is nice :) > > Once again - I'm not sure if starting from scratch is not easier, > especially given the fact that jausoft opengl installation is not > easiest thing to automate. I'm just asking if it is possible to just > reuse it as external library. I checked http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses and we would need to get them to specify another license which is GPL compatible to also release the source under I think, which is provisioned/allowed under their MPL 1.1. The license on most of Mesa appears to be reasonable; the platform support may be good as well. Brian -- Brian Jones <[EMAIL PROTECTED]> ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: java.util.zip speedup
John Leuner wrote: Did you do any profiling of the code? Yes, many times, but only under sun jre 1.4.1 client hotspot on windows. Both cpu and memory. For the cpu, I do not think there are any suprises - most of time is spend in Inflater.decodeHuffman, with InflaterHuffmanTree.getSymbol contributing the most there (most methods called from decodeHuffman get inlined probably). Next parts are Adler32.update and OutputWindow.repeat (last one can be an artifact due to System.arraycopy happening there, providing good point for gc break). I have done small optimalizations in few places, mostly in zip entry reading (it is now about 5 times faster) - but not in actual decompression routines. That's quite an improvement. Are you saying that the current version generates 130MB of garbage, and yours creates 1MB? Yes. This 1MB is not real 'garbage' - most of it are ZipEntry objects, which are actually used by test program. As for 130MB of garbage, most of it comes from OutputWindow allocation. I'm reading over 3000 files from zip, with 32kb byte[] allocated per file, it is already around 90MB. Next part comes from InflaterInputStream (4kb buffer), and quite a few from InflaterHuffmanTree, where temporary arrays are created each time. There is also an incredible amount of small arrays created in ZipEntry creation (for each read, small 2 or 4 byte array is created) - does not influence byte-count of garbage much, but it means that around 10 arrays are allocated per entry. I have done improvements in two major ways. First important one is changing way zip entries are read - it used to read header pieces word after word, I read entry at once - _very_ big improvement at first zip read. I have also removed most of temporary buffer allocations there. Second is caching Inflater. Unfortunately, I have had to hide this caching from world very deep, so there is no chance of somebody messing with cached Inflater in any way. This basically means that only InputStream created by ZipFile will gain this benefit - with ZipInputStream, GZIPInputStream and generic InflaterInputStream we have almost same situation as before. Inflater in turn cache OutputWindow and HuffmanTrees, which cache their temporary arrays. In reset methods I'm doing quite extensive cleaning - somebody with more zip experience probably will be able to remove some of these precautions (I was not sure if at some place there is not dependency on not-touched array element to be zero, so I clear almost all of them, except obvious cases). Cache works ok with multiple threads - just if you have more than one of InputStreams open at same time, second and following ones will produce garbage (I think that in majority of cases single thread is doing most of reading from zip). Could you send me a diff of your changes? Sure, I'm sending them to you in separate mail. Please note that work is not finished - no documentation is done, some in fact is outdated. I would probably also want to move factory methods to separate class. Bearing in mind that the java.util.zip implementation in Classpath is also available as a seperate library, we should consider the needs of people who might want to use this in an embedded system where space is at a premium. Three basic choices here. 1) In current state, there is zero problem with making it configurable. Everything boils down to two 'factory' free methods, which needs to be no-op for embedded case - so some kind of system or static variable will do the trick. 2) We can make Inflater cached at ZipFile instead of system level. When ZipFile is closed, Inflater would be freed - until then it would get reused for all streams from this ZipFile (as long as they are in single thread of course). Problem here is with the systems which would like to keep many ZipFile instances open, 'just in case' - they would pay multiple cost with not benefit. Variation of it is having reference counting for open ZipFiles - to have single static Inflater cache, but empty it when last ZipFile is closed (and recreate if new one is opened). But still you pay 36kb for having ZipFile open (in addition to possibly a lot for ZipEntries). Artur ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: classpath ./ChangeLog java/lang/reflect/Proxy.j...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Montag, 23. Dezember 2002 15:07 schrieb Eric Blake: > Michael Koch wrote: > > CVSROOT:/cvsroot/classpath > > Module name:classpath > > Changes by: Michael Koch <[EMAIL PROTECTED]> 02/12/23 03:30:29 > > > > * java/lang/reflect/Proxy.java > > (h): This member was never final in any jdk release. > > I'm not sure this change needed to be made. The field h is not > publically accessible - it is protected within Proxy, user code > should not extend Proxy directly, and internally created proxy > classes never change the value of h. I thought making it final > (like we made Integer.value final) provided more security from bad > reflection code. Then I wonder why SUN made it non-final ... Integer.value is private and not in the offial API but Proxy.h is (because its protected). We should make our implementation 100% compatible. At least thats a goal. Michael - -- Homepage: http://www.worldforge.org/ GPG-key: http://konqueror.dyndns.org/~mkoch/michael.gpg -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+Bxx2WSOgCCdjSDsRAn11AKCVy0ehRfMyljrAx9QIYng8aYRdEQCZAQ87 X3M9Yk8W0OuBMpUxZKFha+s= =yT6M -END PGP SIGNATURE- ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: classpath ./ChangeLog java/lang/reflect/Proxy.j...
Michael Koch wrote: CVSROOT: /cvsroot/classpath Module name: classpath Changes by: Michael Koch <[EMAIL PROTECTED]> 02/12/23 03:30:29 * java/lang/reflect/Proxy.java (h): This member was never final in any jdk release. I'm not sure this change needed to be made. The field h is not publically accessible - it is protected within Proxy, user code should not extend Proxy directly, and internally created proxy classes never change the value of h. I thought making it final (like we made Integer.value final) provided more security from bad reflection code. -- This signature intentionally left boring. Eric Blake [EMAIL PROTECTED] BYU student, free software programmer ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: java.util.zip speedup
> I have taken java version of java.util.zip from CVS and done few > optimalizations. > > I have zipped entire classpath CVS tree (5MB packed). My test program > goes through all entries and uncompress each to memory array (same every > time, preallocated). I have tested validity of changed by adding write > function to recreate all files - it works ok (after fixing one existing > bug - current version in CVS has problems with unpacking files with 0 > length). Did you do any profiling of the code? > Classpath CVS version needs 3150ms. My optimized version manages to do > it in 2125ms (results vary +-3ms in each case). I think this is quite > reasonable speedup. But real fun comes with memory. Classpath CVS > allocates around 130MB of garbage during processing, my version fits in > 1MB (most of it being zip entries/names). I suppose that most of time > difference comes from less gc work (but I have also made few > optimalizations for reading entries from disk). That's quite an improvement. Are you saying that the current version generates 130MB of garbage, and yours creates 1MB? Could you send me a diff of your changes? > I'm quite shocked to see how fast sun gc is - even if all difference > comes from memory, we are talking about allocating and collecting 130MB > in 1 second - this IS a lot. I suppose that with bigger/more complicated > heap, gc time, and thus difference, would increase considerably. Anyway, > on less advanced jvms, difference in amount of garbage should make > greater impact[1]. > > Now, the ugly part. Few of optimalizations (algorithm and IO-related) > are free. But biggest part (memory savings) require some caching. This > means that around 35kb is allocated first time zip subsystem is used and > will never get freed. There is also a need for quite close look at > inflater sharing versus security. > > My question - is 35kb of memory taken 'forever' an acceptable price for > a lot less garbage on runtime ? Bearing in mind that the java.util.zip implementation in Classpath is also available as a seperate library, we should consider the needs of people who might want to use this in an embedded system where space is at a premium. But obviously for modern workstations this first-time allocation is less important than the speed/memory benefits. John Leuner signature.asc Description: This is a digitally signed message part ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Graphics2D using OpenGL ?
Brian Jones wrote: As this was a research project and is not intended to be supported or developed further and is under the MPL 1.1, is it of any use other than a proof of concept? Even as proof of concept it is nice :) I'm now not telling that we should use this particular library - maybe it will be easier to create it from scratch (I do not like dependency on jausoft opengl binding for example). But in theory, isn't it possible to use it in classpath (outside of contacting people there and asking them to assign copyright to FSF) ? We are using a lot of outside libraries. libc. Used to use libz. Gtk. Xerces (in future for sure). Probably there will be a need to use freetype if fonts are supposed to have any serious functionality. Not all of them use same kind of license as classpath, so it is solved somehow ? I understand that in such case, agile2d would not be distributed as part of classpath. But MPL is quite liberal, we can get it as separate project, hack in any way we want, exposing all needed functions, so it will be a trivial reuse it inside classpath. We would just distribute it as .jar inside classpath, instead putting source here. MPL allows embedding into commercial applications, so it should be not a problem for 'embedded gcc' usage. Once again - I'm not sure if starting from scratch is not easier, especially given the fact that jausoft opengl installation is not easiest thing to automate. I'm just asking if it is possible to just reuse it as external library. Artur ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
