| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
TestJCPP and new TestCParser
|
| |
|
| |
|
|
|
|
| |
path in unit test script for library-path
|
|
|
|
| |
intermediate 'Test' for supporting, non-test classes
|
|
|
|
|
|
| |
927bbc7160a812bb29c0e7120d4a3009bfb13bbf
Almost done
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
added code generation incl. native to Java dispatch and resource management
Tested via Test4JavaCallback.java (using test2.[hc]).
Please read the GlueGen_Mapping.md as well as Test4JavaCallback.java .
+++
Some implementation details:
JavaConfiguration maps JavaCallbackDef to JavaCallback set-function and maintains a list.
JavaCallbackDef itself holds all configured details.
JavaConfiguration also maps JavaCallbackInfo to JavaCallback set-function.
JavaCallbackInfo itself holds all compile time information, as produced by JavaEmitter.beginFunctions(..).
This extends JavaCallbackDef and avoid repetetive computation for the callback-function-type and its MethodBinding,
parameter indices for the callback interface and userParam, etc.
CMethodBindingEmitter: Native callback to Java dispatch
- The JavaCallback setter function creates a native 'UserParam' struct instance,
which holds the callback-interface-jobject, its callback-jmethodID and
the userParam-jobject for invocation of the actual JavaCallback interface method.
- To produce the C-Type -> JNI-Type conversion, An internal CMethodBindingEmitter instance
for the native-callback function binding is created inside the CMethodBindingEmitter of the callback setter method.
It is being used to map the types to JNI within the generated native callback function,
passed to the actual JavaCallback method.
JavaMethodBindingEmitter: Native callback to Java dispatch
- The JavaCallbacl setter passes the callback-interface-object, the userParam-object and the
callback-method-signature (to have the native method retrieve the jmethodID).
- It receives the native pointer of the native `UserParam` struct instance,
which gets mapped to the userParam-object. (*TODO: Refine ownership + release*).
|
|
|
|
| |
See documentation and unit test test2.h, Test2FuncPtr.java and Test3PtrStorage.java
|
| |
|
|
|
|
| |
documentation
|
|
|
|
| |
required by System.load*()
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Test1p1Test1p1JavaEmitter
'com.jogamp.gluegen.test.junit.generation.Test1p1JavaEmitter' exposes a regression
using MingW64 8.1.0: System.loadLibrary() gives a "Can't find dependent libraries".
Here, 'Bindingtest1p1' is linked against 'test1' and fails to load
due to its wrong dependent library name within 'Bindingtest1p1'.
MingW64 8.1.0 dropped 'libtest1.so' into 'Bindingtest1p1.dll',
which is surely wrong. Even passing '-Wl,-soname=test1.dll' didn't help.
Note: Such constellation would only work with adding
the lib-path to PATH on Windows.
Since we don't utilize the method in any of our projects,
but use the dynamic library lookup method - this is not a blocker,
but wasted some good time.
|
|
|
|
|
| |
Implementation currently uses 256 bit Secure Hash (SHA) algorithm, but this may change in the future.
Hence only use 'SHA' in the names, not 'SHA256'.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
runtime validation
This change implements a strong SHA256 signature over:
1) source tree inclusive make recipe (SHA256-Source)
2) all class files (SHA256-Classes)
3) all native libraries (SHA256-Natives)
4) the class files as deployed in the jar (SHA256-Classes-this)
5) the native libraries as deployed in the jar (SHA256-Natives-this)
and drops all of these in the deployed Jar file.
This allows SHA256 validation of (4) + (5) at runtime
and further complete validation (1), (2) and (3) offline.
Full SCC would now required (1) - (3) to be placed on a server for further validation.
Optionally we may use GPG <https://gnupg.org/> or PGP to validate the build entity to implement the chain of trust <https://en.wikipedia.org/wiki/Chain_of_trust>
The SHA256 runtime validation is tested via: com.jogamp.common.util.TestVersionInfo
|
|
|
|
|
|
|
|
| |
Since Java8 (or even earlier), JRE on OSX uses *.dylib native library suffix
instead of *.jnilib when automatically searching and loading them.
This is not easily being recognized by JogAmp, since we explicitly name
the native libraries with full path when testing with our TempJarCache.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Re-adding executable test by execution is required for 'blocker technology'
like Windows's 'Software Restriction Policies (SRP)',
which only gets activated by the actual execution attempt.
Merely testing the file's (ACL) execution flags via NIO's isExecutable is not sufficient.
Implementation first tests the file's (ACL) execution flags via NIO's isExecutable.
If the NIO test was successful or not available, the actual execution test is performed.
To mitigate the virus scanner's false positive, we use an executable shell script
per default now, which may be overriden by the new environment 'jogamp.gluegen.UseNativeExeFile=true'
Tested on GNU/Linux with one temp folder having mount options 'noexec'
and on Windows using Software Restriction Policies (SRP) disallowing one temp folder.
Both temp folder were first in line via environment 'java.io.tmpdir'.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
java.nio.file.Files.isExecutable(Path)
Attempt to resolved virus scanner false positive detection on Windows
while deflating the native code test-exe file in the temporary folder.
As Julien Gouesse suggested, using Java 1.7's java.nio.file.Files.isExecutable(Path)
_may_ resolve the issue, this has to be thorougly tested.
This patch favors the nio's isExecutable file's ACL test
over the more intrusive execution itself using a simple shell script file w/ set executable flag.
Mind that previous tests allowed the shell script's execution,
even if the temp folder did not allow execution of native code.
We have to see how our testing results will be on this attempt.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Uri to handle relative path
Fix IOUtil.cleanPathString(..) special case:
Special case '/a/./../b' -> '/b'
requires to resolve './' before '../'.
Allow IOUtil and Uri to handle relative path:
- IOUtil.getParentOf(..)
- IOUtil.cleanPathString(..)
Handle cases:
'a/./../b' -> 'b'
'.././b' -> '../b'
- Uri: Handle null scheme
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
IOUtil.testDirExe():
- Satisfactory when executed
Failure to execute produce an IOException right at ProcessBuilder.start().
Hence we can allow an unexpected process exit value,
since we only want to learn whether executable files are allowed.
- More debug options
DEBUG_EXE: 'jogamp.debug.IOUtil.Exe'
DEBUG_EXE_NOSTREAM: 'jogamp.debug.IOUtil.Exe.NoStream'
- if DEBUG_EXE
- a pre-existing 'jogamp_exe_tst'+<SUFFIX> will be used as-is.
- the test-exe will not be deleted
- StreamMonitor is being used to dump stdout/stderr
if !DEBUG_EXE_NOSTREAM.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Windows using 'exe-windows-i586-268b.bin' (Fix attempt #1)
Replacing the tiny 268 byte sized 'exe-windows-i586-268b.bin' PE file
w/ a regular 2048 byte sized PE file 'exe-windows-i386-2048b.bin'.
File is produced via:
c:\mingw\bin\gcc -nodefaultlibs -nostdlib -s -Os -o tiny.exe tiny.c
Adding the 305 byte sized gzipped version 'exe-windows-i386-2048b.bin.305b.gz'
to the gluegen-rt jar file to reduce the payload for non Windows platforms.
Adding special property 'jogamp.debug.IOUtil.Exe' to debug testing the exe file,
enable via '-Djogamp.debug.IOUtil.Exe'.
Passes here on all Windows machines, however, the prev. one worked here as well.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Use InterruptSource.Thread.create(..),
while reducing InterruptSource.Thread ctors to 3 variants.
- Use InterruptSource.Thread instead of java.lang.Thread where possible
- Use SourcedInterruptedException where possible
- SingletonInstanceServerSocket: start(), stop() and run()
- Persistent-Wait and Cancelable
- Add @since 2.3.2
|
|
|
|
| |
'jogamp.debug.JNILibLoader.Perf'
|
|
|
|
|
|
|
|
| |
'natives/os.and.arch', reducing JAR search.
Since all native libraries are now contained within 'natives/os.and.arch',
we don't need to search the whole JAR file anymore
but simply can copy the content of the defined folder - if existing.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
PlatformPropsImpl.findSysLib(..).
This patch partially reverts of commit d12e4d4ea279998b27457691038e709879dcaca6.
NativeLibrary.open(..) requires search of system libraries,
since it loads the actual 'tool library' for which we generate the JNI binding.
The 'tool library' is preferably the system wide installed version,
e.g. libGL.so etc.
PlatformPropsImpl.findSysLib(..) also requires finding system libraries
as needed for PlatformPropsImpl.queryElfFile(..), i.e. using libjava.so etc.
Only the JNI 'glue library', glueing java calls to the 'tool library',
shall not use the system wide library search since we shall only use
JogAmp provided instances here.
This patch also reinstates binary compatibility w/ prev. GlueGen JARs
since NativeLibrary.enumerateLibraryPath(..) is public.
+++
Further more 'NativeLibrary.enumerateLibraryPath(..)'
now adds OSX system framework search _before_ the user path
in case 'searchSystemPath && searchSystemPathFirst'.
Original code always added this search to the end,
which does not match the intended behavior (-> bug).
|
|
|
|
| |
and bitCount(), add unit test (passed)
|
|
|
|
| |
tests
|
| |
|
|
|
|
|
|
| |
ArrayHashMap; Unify ctor for both impl.
Add/Enhance unit tests for both.
|
|
|
|
| |
-> v23x
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
regexp-constant and java-parser. (Due to PCPP -> JCPP)
Lack of parsing binary exponent floats is exposed due to using JCPP
and correct constant-definitions.
- JavaParser.g:
- Add support for hexadecimal w/ binary exponent floats
- TAB -> 4 spaces
- ConstantDefinition.java:
- Add RegExp 'fpRegexp', patternDecimalNumber:
decimal number w/ support for hexadecimal w/ binary exponent floats.
- isDecimalNumber(..): Use patternDecimalNumber
instead of try-and-error (NumberFormatException)
- patternCPPOperand: exclude patternDecimalNumber!
- JavaEmitter.java:
- Respect explicit suffix [dD] for double type.
- Drop floating point suffixes [fF]
- Test: Added tests for hexadecimal w/ binary exponent floats
|
|
|
|
| |
JCPP submodule, build, test and doc)
|
|
|
|
|
|
|
|
| |
MethodBinding/FunctionBinding Semantics
- Clarify name semantics: name -> [interfaceName, implName, nativeName]
- JavaMethodBindingEmitter: Refine native identity via isNativeMethod + isPrivateNativeMethod
- ProcAddressEmitter: Remove hack whether we need to wrap .. use isNativeMethod + isPrivateNativeMethod
|
|
|
|
| |
reduce test time (was: > 10 min)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- We shall be able to import 'most' vanilla GL header,
i.e. only change the typedef part using our GlueGen types
- Type Safety:
- GlueGen now detects '#define' and 'enum' redefines
and throw an exception in this case.
This helps detecting wrongly renamed GL extensions into core!
- GlueGen now detects function redefines (overloading)
and throw an exception in this case.
Hence the semantics of duplicate functions has to be equal!
This helps detecting wrongly renamed GL extensions into core!
- Semantic equality for all types is provided
via interface TypeComparator.SemanticEqualityOp, i.e. 'boolean equalSemantics(..)'
implemented by com.jogamp.gluegen.cgram.types.Type.
Semantic equality can be relaxed via config "RelaxedEqualSemanticsTest true",
i.e. ignoring integer size, and const / volatile qualifiers.
- All equality/hash methods of 'com.jogamp.gluegen.cgram.types.*'
are restructured.
- Track and simplify renamed 'symbol', i.e. use a common
sub-interface for all renamed symbols (ConstantDefinition, FunctionSymbol, ..)
- This is provided in a unified manner
via interface com.jogamp.gluegen.cgram.types.AliasedSymbol
and its common implementation AliasedSymbolImpl
- All JavaConfiguration.shouldIgnore* methods operate w/
'AliasedSymbol' trying to match all aliases.
- Support 'struct NAME [ { ... } ]' w/o typedef's
- New GL / CL headers do not use typedef's for anonymous opaque types
- Opaque Type handling
- JavaConfiguration.typeInfo(..), identifying opaque types,
no more back references from target-type -> typedef.
Hence the following is possible now:
typedef void * Opaque01; // Opaque
typedef void * APointerBuffer; // A Buffer
- All Logger instances are no more static
and derive their warning level from the package's root Logger
via Logging.getLogger(..).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
matching StaticConfig at runtime; Fix PPC (Bug 1056) and MIPSLE (Bug 1014) issues.
Currently the StaticConfig is being queried
via the key[OSType, CPUType ..]
as pre-determined by Java properties or the ELF parser.
This adds complication to maintain different platforms
and the key query might not even be sufficient.
The MachineDescriptor's StaticConfig only purpose shall be
to speed-up native data size and offset/alignment retrieval.
This is done by using the StaticConfig index within
all StaticConfig[]s as a lookup-index for the precomputed
struct's size and offset tables.
+++
Solution:
Rename: MachineDescriptor -> MachineDataInfo
Rename: MachineDescriptorRuntime -> MachineDataInfoRuntime
After having defined os.and.arch (OSType, CPUType and ABIType)
w/ the optional help of the now self containing ELF Reader (Bug 1125),
the native gluegen-rt library gets loaded enabling JNI methods.
It is satisfactory to retrieve MachineDataInfo
at runtime w/ JNI and find the matching/compatible StaticConfig.
Only in case none is found, the program needs to abort.
Otherwise the found MachineDataInfo.StaticConfig and MachineDataInfo
are stored for further use (see above).
This removes above complication and key to StaticConfig mapping.
New platforms simply need to add a new unique entry into the
StaticConfig[] table.
++
Also fixes Bug 1056 (PPC), thanks to tmancill [@] debian [.] org,
and Bug 1014 (MIPSLE), thanks to Dejan Latinovic.
Parts of the patch for Bug 1014 from Dejan Latinovic are included.
also solved by this change set.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ELF Reader 'jogamp.common.os.elf' currently uses
Platform's pre-determined OS_TYPE and CPUType.
It also uses the host platforms MachineDescription,
hence can not read ELF files from other machines.
This also forbids Platform to determine CPUType etc
w/o having a valid 'os.arch' property.
+++
ElfHeader should be split in
- ElfHeaderPart1 (CPUType independent)
- ElfHeaderPart2 (CPUType dependent)
Fix shall make the ELF Reader self containing
by only using ELF CPUType data, etc.
This requires customization of struct parsing,
where MachineDescription.Static index shall be
- defined in ElfHeaderPart1 using e_Ident's CPUType.
- used in ElfHeaderPart2 and all its struct types.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
access permission on Windows via BATCH file execution
Try using explicit call to Windows 'cmd.exe' w/ referencing the BATCH file location,
via
'Runtime.getRuntime().exec(new String[] { "cmd", "/c", "a.bat" } );'
While the bug itself could not be reproduced here,
I could test on Windows 7 (64bit and 32bit), as well as an WindowsXP 32bit
that no regression occured.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
setting of stream position (optional)
- Add setting position entry, optionally supported,
e.g. ByteBufferStream and ByteArrayStream
- Remove 'msbFirst' parameter on all 'bulk' read/write
operations.
These methods use LSB-first always, allowing proper
stream access of data w/ different bit-sizes.
Data is now read/write as little-endian
and swapped accordingly.
Optimizations are adopted for LSB-first operations.
This change removes API confusion/bugs:
- removes one decision (parameter)
- removes the data reversion case
- removes bugs w/ different bit-sizes
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Validate active and GC'ed mapped-buffer count
in cleanAllSlices() via close() ..
- Fix missing unmapping last buffer in notifyLengthChangeImpl(),
branch criteria was off by one.
- cleanSlice(..) now also issues cleanBuffer(..) on the GC'ed entry,
hence if WeakReference is still alive, enforce it's release.
- cleanBuffer(..) reverts FLUSH_PRE_HARD -> FLUSH_PRE_SOFT
in case of an error.
- flush() -> flush(boolean metaData) to expose FileChannel.force(metaData).
- Add synchronous mode, flushing/syncing the mapped buffers when
in READ_WRITE mapping mode and issue FileChannel.force() if not READ_ONLY.
Above is implemented via flush()/flushImpl(..) for buffers and FileChannel,
as well as in syncSlice(..) for buffers only.
flush*()/syncSlice() is covered by:
- setLength()
- notifyLengthChange*(..)
- nextSlice()
Always issue flushImpl() in close().
- Windows: Clean all buffers in setLength(),
otherwise Windows will report:
- Windows: Catch MappedByteBuffer.force() IOException
- Optimization of position(..)
position(..) is now standalone to allow issuing flushSlice(..)
before gathering the new mapped buffer.
This shall avoid one extra cache miss.
Hence rename positionImpl(..) -> position2(..).
- All MappedByteBufferOutputStream.write(..) methods
issue syncSlice(..) on the last written current slice
to ensure new 'synchronous' mode is honored.
+++
Unit tests:
- Ensure test files are being deleted
- TestByteBufferCopyStream: Reduced test file size to more sensible values.
-
|
|
|
|
| |
to stream copy as well as direct memory mapped ByteBuffer access
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
OutputStream impl.
Added MappedByteBufferOutputStream as a child instance of MappedByteBufferInputStream,
since the latter already manages the file's mapped buffer slices.
Current design is:
- MappedByteBufferInputStream (parent)
- MappedByteBufferOutputStream
this is due to InputStream and OutputStream not being interfaces,
but most functionality is provided in one class.
We could redesign both as follows:
- MappedByteBufferIOStream (parent)
- MappedByteBufferInputStream
- MappedByteBufferOutputStream
This might visualize things better .. dunno whether its worth the
extra redirection.
+++
MappedByteBufferInputStream:
- Adding [file] resize support via custom FileResizeOp
- All construction happens via ctors
- Handle refCount, incr. by ctor and getOutputStream(..), decr by close
- Check whether stream is closed already -> IOException
- Simplify / Reuse code
MappedByteBufferOutputStream:
- Adding simple write operations
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
InputStream impl., incl. mark/reset
- ByteBufferInputStream simply impl. InputStream for an arbitrary 2MiB restricted ByteBuffer
- Users may only need a smaller implementation for 'smaller' file sizes
or for streaming a [native] ByteBuffer.
- MappedByteBufferInputStream impl. InputStream for any file size,
while slicing the total size to memory mapped buffers via the given FileChannel.
The latter are mapped lazily and diff. flush/cache methods are supported
to ease virtual memory usage.
- TestByteBufferInputStream: Basic unit test for basic functionality and perf. stats.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
for getNormalized(), getDirectory(), getParent() and getRelativeOf()
- Refine API doc
- Add notion of {@code host} and {@code port} validation
- Add create(Encoded ..), allowing creation of variants w/o re-encoding
- Provide common impl. for getNormalized(), getDirectory(), getParent() and getRelativeOf()
Above feature methods share common goals, hence use same implementation:
- If opaque, cut-off query and merge after operation
- cleanup path, i.e. /dummy/../test/ -> /test/
- cutoff file, dir - if requested
- append optional appendix and cleanup again
Return behavior various thought, i.e. null, this or allow exception.
Enhanced test of above features.
|
| |
|