[jira] [Comment Edited] (THRIFT-1418) Compiling Thrift from source: Class org.apache.tools.ant.taskdefs.ConditionTask doesn't support the nested "typefound" element

2018-01-19 Thread Alexander Volanis (JIRA)

[ 
https://issues.apache.org/jira/browse/THRIFT-1418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16332772#comment-16332772
 ] 

Alexander Volanis edited comment on THRIFT-1418 at 1/19/18 10:50 PM:
-

I believe the right fix for this is to keep the `make all` and `make install` 
as independent tasks without explicit dependencies. `make all` generates a 
local build tree location with the distribution JAR files and `make install` 
simply copies that to $DESTDIR or $CMAKE_INSTALL_PREFIX as customary.

My solution fixes this by allowing `sudo make install/fast` to execute 
correctly.


was (Author: alex-vol):
I believe the right fix for this is to keep the `make all` and `make install` 
as independent tasks without explicit dependencies. `make all` generates a 
local build tree location with the distribution JAR files and `make install` 
simply copies that to $DESTDIR or $CMAKE_INSTALL_PREFIX as customary.

> Compiling Thrift from source: Class 
> org.apache.tools.ant.taskdefs.ConditionTask doesn't support the nested 
> "typefound" element
> --
>
> Key: THRIFT-1418
> URL: https://issues.apache.org/jira/browse/THRIFT-1418
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Compiler
>Affects Versions: 0.7
> Environment: CentOS 5.5, Ant 1.8.2, Java 1.6.0_13-b03
>Reporter: Robert A. Lerche
>Priority: Major
> Attachments: compile-thrift
>
>
> I am trying to build Thrift from source in the above configuration.  "make" 
> succeeds but "sudo make install" gives the error shown.  I attach the build 
> log.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[GitHub] thrift issue #1468: Thrift 4259: Thrift does not compile due to Ant Maven ta...

2018-01-19 Thread Alex-Vol
Github user Alex-Vol commented on the issue:

https://github.com/apache/thrift/pull/1468
  
Right after I pushed the last commit with the sources restored to the 
original locations I found the sonar-project.properties file that had a 
reference to the new source code layout.

Assuming this is a green build now it is ready for final review. @jeking3 
if you could let interested parties in the dev discussion list know about the 
PR I would appreciate it.


---


[jira] [Commented] (THRIFT-1507) Maven can't download resource from central when behind a proxy and won't use local repository

2018-01-19 Thread Alexander Volanis (JIRA)

[ 
https://issues.apache.org/jira/browse/THRIFT-1507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16332774#comment-16332774
 ] 

Alexander Volanis commented on THRIFT-1507:
---

Decoupling the task dependency between `make all` and `make install` can 
correct this deficiency. There is no need to redo the build step when `make 
install` is invoked. This would allow `sudo make install` to be a very quick 
copy-only task.

> Maven can't download resource from central when behind a proxy and won't use 
> local repository
> -
>
> Key: THRIFT-1507
> URL: https://issues.apache.org/jira/browse/THRIFT-1507
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Library
>Affects Versions: 0.8
> Environment: Ubuntu 10.04 LTS, running in a VM in VMWare Player 
> hosted on Windows XP Pro which is behind a proxy server.
>Reporter: Mark Anderson
>Assignee: Jake Farrell
>Priority: Major
>  Labels: build, maven
>
> When 'make' enters lib/java, the build fails on the mvn.init target with:
> . . .
> [artifact:dependencies] [WARNING] Overriding profile: 
> 'maven-ant-tasks-repo-profile' (source: pom) with new instance from source: 
> pom
> [artifact:dependencies] Downloading: 
> org/slf4j/slf4j-api/1.5.8/slf4j-api-1.5.8.pom from repository central at 
> http://repo1.maven.org/maven2
> [artifact:dependencies] Error transferring file: Connection refused
> [artifact:dependencies] [WARNING] Unable to get resource 
> 'org.slf4j:slf4j-api:pom:1.5.8' from repository central 
> (http://repo1.maven.org/maven2): Error transferring file: Connection refused
> . . .
> This occurs for every dependency in the 'pom' artifact (on some files, the 
> error is "Connection timed out").
> The preceding target, mvn.ant.tasks.download, succeeds (the 
> maven-ant-tasks-2.1.3.jar file is sitting in the tools directory).
> I have added to build.xml:
> proxy.host=proxy1.domain.com
> proxy.port=80
> proxy.user=
> proxy.pass=
> proxy.enabled=true
> and to /etc/maven2/settings.xml:
>  
>   proxy1
>   true
>   http
>   proxy1.domain.com
>   80
>   localhost
> 
> Maven does not seem to be picking up the proxy.  If I manually download all 
> the resources and install them into my local repository (~/.m2/repository) as 
> suggested and re-run make, I still get the errors -- Maven doesn't try to use 
> the local repository.
> If I move the machine out from behind the firewall, everything works fine: 
> Maven downloads all the dependencies and the Java stuff is able to be built.  
> If I then put the machine back behind the firewall and run 'sudo make 
> install', Maven again tries to download the dependencies from central and 
> that, of course, fails.  It doesn't realize that all the dependencies have 
> been downloaded and the Java files have been compiled.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (THRIFT-1418) Compiling Thrift from source: Class org.apache.tools.ant.taskdefs.ConditionTask doesn't support the nested "typefound" element

2018-01-19 Thread Alexander Volanis (JIRA)

[ 
https://issues.apache.org/jira/browse/THRIFT-1418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16332772#comment-16332772
 ] 

Alexander Volanis commented on THRIFT-1418:
---

I believe the right fix for this is to keep the `make all` and `make install` 
as independent tasks without explicit dependencies. `make all` generates a 
local build tree location with the distribution JAR files and `make install` 
simply copies that to $DESTDIR or $CMAKE_INSTALL_PREFIX as customary.

> Compiling Thrift from source: Class 
> org.apache.tools.ant.taskdefs.ConditionTask doesn't support the nested 
> "typefound" element
> --
>
> Key: THRIFT-1418
> URL: https://issues.apache.org/jira/browse/THRIFT-1418
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Compiler
>Affects Versions: 0.7
> Environment: CentOS 5.5, Ant 1.8.2, Java 1.6.0_13-b03
>Reporter: Robert A. Lerche
>Priority: Major
> Attachments: compile-thrift
>
>
> I am trying to build Thrift from source in the above configuration.  "make" 
> succeeds but "sudo make install" gives the error shown.  I attach the build 
> log.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (THRIFT-4461) Compiler directive should match Delphi XE4

2018-01-19 Thread Jens Geyer (JIRA)

 [ 
https://issues.apache.org/jira/browse/THRIFT-4461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jens Geyer resolved THRIFT-4461.

   Resolution: Fixed
Fix Version/s: 0.12.0

Committed, thanks!

> Compiler directive should match Delphi XE4
> --
>
> Key: THRIFT-4461
> URL: https://issues.apache.org/jira/browse/THRIFT-4461
> Project: Thrift
>  Issue Type: Bug
>  Components: Delphi - Library
>Affects Versions: 0.11.0
> Environment: Delphi XE3
>Reporter: Anton Shchyrov
>Assignee: Jens Geyer
>Priority: Minor
>  Labels: delphi
> Fix For: 0.12.0
>
> Attachments: Thrift.Utils.diff
>
>
> In module Thrift.Utils daclared two methods
> {{class function CharUtils.IsHighSurrogate( const c : Char) : Boolean;}}
> {{begin}}
> {{  \{$IF CompilerVersion < 23.0}}}
> {{  result := Character.IsHighSurrogate( c);}}
> {{  \{$ELSE}}}
> {{  result := c.IsHighSurrogate();}}
> {{  \{$IFEND}}}
> {{end;}}
> {{class function CharUtils.IsLowSurrogate( const c : Char) : Boolean;}}
> {{begin}}
> {{  \{$IF CompilerVersion < 23.0}}}
> {{  result := Character.IsLowSurrogate( c);}}
> {{  \{$ELSE}}}
> {{  result := c.IsLowSurrogate;}}
> {{  \{$IFEND}}}
> {{end;}}
> But methods Char.IsHighSurrogate()/Char.IsLowSurrogate() **appeared in Delphi 
> XE4. For Delphi XE4 variable CompilerVersion equal 25.
> In this way condition
> {{{$IF CompilerVersion < 23.0}}}
> may be changed to
> {{{$IF CompilerVersion < *25.0*}}}
> And access for unit *Character* may be determined through defiine symbol 
> *OLD_UNIT_NAMES*



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (THRIFT-4462) First line in Console duplicated

2018-01-19 Thread Jens Geyer (JIRA)

 [ 
https://issues.apache.org/jira/browse/THRIFT-4462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jens Geyer resolved THRIFT-4462.

   Resolution: Fixed
Fix Version/s: 0.12.0

Committed, thanks!

> First line in Console duplicated
> 
>
> Key: THRIFT-4462
> URL: https://issues.apache.org/jira/browse/THRIFT-4462
> Project: Thrift
>  Issue Type: Bug
>  Components: Delphi - Library
>Affects Versions: 0.11.0
>Reporter: Anton Shchyrov
>Assignee: Jens Geyer
>Priority: Minor
> Fix For: 0.12.0
>
> Attachments: Thrift.Console.patch
>
>
> Method Console.Write/WriteLine in class TGUIConsole after called method 
> *Write* and clear log duplicates current message
> {{ChangeConsole(TGUIConsole.Create(Memo1.Lines));}}
> {{Console.Write('String');  // Set internal FLineBreak to False}}
> {{Memo1.Lines.Clear;}}
> {{Console.Write('Some String');  // Log have "Some StringSome String"}}
> Reason in method 
> {{procedure TGUIConsole.InternalWrite(const S: string; bWriteLine: Boolean);}}
> {{var}}
> {{  idx : Integer;}}
> {{begin}}
> {{  if FLineBreak then}}
> {{  begin}}
> {{    FMemo.Add( S );}}
> {{  end else}}
> {{  begin}}
> {{    idx := FMemo.Count - 1;}}
> {{    if idx < 0 then}}
> {{    begin}}
> {{      FMemo.Add( S );}}
> {{    end;}}
> {{    FMemo[idx] := FMemo[idx] + S;}}
> {{  end;}}
> {{  FLineBreak := bWriteLine;}}
> {{end;}}
> If FMemo.Count = 0 then idx = -1 and string added to log. But next line
> {{FMemo[idx] := FMemo[idx] + S;}}
> repeats the added string. should be
>     if idx < 0 then
>     begin
>       FMemo.Add( S );
>     end *else*
>       FMemo[idx] := FMemo[idx] + S;



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (THRIFT-4462) First line in Console duplicated

2018-01-19 Thread Jens Geyer (JIRA)

 [ 
https://issues.apache.org/jira/browse/THRIFT-4462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jens Geyer updated THRIFT-4462:
---
Summary: First line in Console duplicated  (was: Incorrect first line in 
Console)

> First line in Console duplicated
> 
>
> Key: THRIFT-4462
> URL: https://issues.apache.org/jira/browse/THRIFT-4462
> Project: Thrift
>  Issue Type: Bug
>  Components: Delphi - Library
>Affects Versions: 0.11.0
>Reporter: Anton Shchyrov
>Assignee: Jens Geyer
>Priority: Minor
> Attachments: Thrift.Console.patch
>
>
> Method Console.Write/WriteLine in class TGUIConsole after called method 
> *Write* and clear log duplicates current message
> {{ChangeConsole(TGUIConsole.Create(Memo1.Lines));}}
> {{Console.Write('String');  // Set internal FLineBreak to False}}
> {{Memo1.Lines.Clear;}}
> {{Console.Write('Some String');  // Log have "Some StringSome String"}}
> Reason in method 
> {{procedure TGUIConsole.InternalWrite(const S: string; bWriteLine: Boolean);}}
> {{var}}
> {{  idx : Integer;}}
> {{begin}}
> {{  if FLineBreak then}}
> {{  begin}}
> {{    FMemo.Add( S );}}
> {{  end else}}
> {{  begin}}
> {{    idx := FMemo.Count - 1;}}
> {{    if idx < 0 then}}
> {{    begin}}
> {{      FMemo.Add( S );}}
> {{    end;}}
> {{    FMemo[idx] := FMemo[idx] + S;}}
> {{  end;}}
> {{  FLineBreak := bWriteLine;}}
> {{end;}}
> If FMemo.Count = 0 then idx = -1 and string added to log. But next line
> {{FMemo[idx] := FMemo[idx] + S;}}
> repeats the added string. should be
>     if idx < 0 then
>     begin
>       FMemo.Add( S );
>     end *else*
>       FMemo[idx] := FMemo[idx] + S;



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (THRIFT-4461) Compiler directive should match Delphi XE3

2018-01-19 Thread Jens Geyer (JIRA)

 [ 
https://issues.apache.org/jira/browse/THRIFT-4461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jens Geyer updated THRIFT-4461:
---
Summary: Compiler directive should match Delphi XE3  (was: Invalid compiler 
directive)

> Compiler directive should match Delphi XE3
> --
>
> Key: THRIFT-4461
> URL: https://issues.apache.org/jira/browse/THRIFT-4461
> Project: Thrift
>  Issue Type: Bug
>  Components: Delphi - Library
>Affects Versions: 0.11.0
> Environment: Delphi XE3
>Reporter: Anton Shchyrov
>Assignee: Jens Geyer
>Priority: Minor
>  Labels: delphi
> Attachments: Thrift.Utils.diff
>
>
> In module Thrift.Utils daclared two methods
> {{class function CharUtils.IsHighSurrogate( const c : Char) : Boolean;}}
> {{begin}}
> {{  \{$IF CompilerVersion < 23.0}}}
> {{  result := Character.IsHighSurrogate( c);}}
> {{  \{$ELSE}}}
> {{  result := c.IsHighSurrogate();}}
> {{  \{$IFEND}}}
> {{end;}}
> {{class function CharUtils.IsLowSurrogate( const c : Char) : Boolean;}}
> {{begin}}
> {{  \{$IF CompilerVersion < 23.0}}}
> {{  result := Character.IsLowSurrogate( c);}}
> {{  \{$ELSE}}}
> {{  result := c.IsLowSurrogate;}}
> {{  \{$IFEND}}}
> {{end;}}
> But methods Char.IsHighSurrogate()/Char.IsLowSurrogate() **appeared in Delphi 
> XE4. For Delphi XE4 variable CompilerVersion equal 25.
> In this way condition
> {{{$IF CompilerVersion < 23.0}}}
> may be changed to
> {{{$IF CompilerVersion < *25.0*}}}
> And access for unit *Character* may be determined through defiine symbol 
> *OLD_UNIT_NAMES*



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (THRIFT-4461) Compiler directive should match Delphi XE4

2018-01-19 Thread Jens Geyer (JIRA)

 [ 
https://issues.apache.org/jira/browse/THRIFT-4461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jens Geyer updated THRIFT-4461:
---
Summary: Compiler directive should match Delphi XE4  (was: Compiler 
directive should match Delphi XE3)

> Compiler directive should match Delphi XE4
> --
>
> Key: THRIFT-4461
> URL: https://issues.apache.org/jira/browse/THRIFT-4461
> Project: Thrift
>  Issue Type: Bug
>  Components: Delphi - Library
>Affects Versions: 0.11.0
> Environment: Delphi XE3
>Reporter: Anton Shchyrov
>Assignee: Jens Geyer
>Priority: Minor
>  Labels: delphi
> Attachments: Thrift.Utils.diff
>
>
> In module Thrift.Utils daclared two methods
> {{class function CharUtils.IsHighSurrogate( const c : Char) : Boolean;}}
> {{begin}}
> {{  \{$IF CompilerVersion < 23.0}}}
> {{  result := Character.IsHighSurrogate( c);}}
> {{  \{$ELSE}}}
> {{  result := c.IsHighSurrogate();}}
> {{  \{$IFEND}}}
> {{end;}}
> {{class function CharUtils.IsLowSurrogate( const c : Char) : Boolean;}}
> {{begin}}
> {{  \{$IF CompilerVersion < 23.0}}}
> {{  result := Character.IsLowSurrogate( c);}}
> {{  \{$ELSE}}}
> {{  result := c.IsLowSurrogate;}}
> {{  \{$IFEND}}}
> {{end;}}
> But methods Char.IsHighSurrogate()/Char.IsLowSurrogate() **appeared in Delphi 
> XE4. For Delphi XE4 variable CompilerVersion equal 25.
> In this way condition
> {{{$IF CompilerVersion < 23.0}}}
> may be changed to
> {{{$IF CompilerVersion < *25.0*}}}
> And access for unit *Character* may be determined through defiine symbol 
> *OLD_UNIT_NAMES*



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[GitHub] thrift issue #1468: Thrift 4259: Thrift does not compile due to Ant Maven ta...

2018-01-19 Thread Alex-Vol
Github user Alex-Vol commented on the issue:

https://github.com/apache/thrift/pull/1468
  
I have identified the following issues as duplicates or related to this. 


[THRIFT-4178](https://issues.apache.org/jira/projects/THRIFT/issues/THRIFT-4178)

[THRIFT-4120](https://issues.apache.org/jira/projects/THRIFT/issues/THRIFT-4120)

[THRIFT-3983](https://issues.apache.org/jira/projects/THRIFT/issues/THRIFT-3983)

[THRIFT-1507](https://issues.apache.org/jira/projects/THRIFT/issues/THRIFT-1507)

[THRIFT-1418](https://issues.apache.org/jira/projects/THRIFT/issues/THRIFT-1418)

[THRIFT-4294](https://issues.apache.org/jira/projects/THRIFT/issues/THRIFT-4294)

Most are already fixed, the ones relating to running `sudo make install` 
can be addressed in this PR easily so I am going to tackle the task now.

Regarding the source code move, I will move it back and propose a layout 
organization as a separate option. It will make reviewing this by a larger 
group much easier without the noise of the move.


---


[jira] [Commented] (THRIFT-4178) Java libraries missing from package when using cmake

2018-01-19 Thread Alexander Volanis (JIRA)

[ 
https://issues.apache.org/jira/browse/THRIFT-4178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16332650#comment-16332650
 ] 

Alexander Volanis commented on THRIFT-4178:
---

This can be addressed by changes in THRIFT-4259. I will see about making the 
necessary corrections.

> Java libraries missing from package when using cmake
> 
>
> Key: THRIFT-4178
> URL: https://issues.apache.org/jira/browse/THRIFT-4178
> Project: Thrift
>  Issue Type: Bug
>  Components: Build Process, Java - Library
>Reporter: Arnaud Lacombe
>Priority: Major
>
> The CMake infrastructure fails to include the java libraries in the generated 
> package. Instead, the libraries are wrongly installed on the build host. The 
> problem is likely due to the following line:
> lib/java/CMakeLists.txt:
> {noformat}
> [...]
> # Hook the ant install task into CMake install
>   
> 
> install(CODE "execute_process(
> COMMAND ${Ant_EXECUTABLE} ${ANT_FLAGS} install
>   
> 
> -Dbuild.dir=\"${CMAKE_CURRENT_BINARY_DIR}\"
> -Dinstall.path=\"${JAVA_INSTALL_DIR}\" 
> -Dinstall.javadoc.path=\"${JAVA_DOC_INSTALL_DIR}\" -f build.xml
> WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR} 
>   
> 
> )")
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Comment Edited] (THRIFT-4461) Invalid compiler directive

2018-01-19 Thread Anton Shchyrov (JIRA)

[ 
https://issues.apache.org/jira/browse/THRIFT-4461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16332593#comment-16332593
 ] 

Anton Shchyrov edited comment on THRIFT-4461 at 1/19/18 5:39 PM:
-

Full unit name System.Character. This unit added in Thrift.Utils by scheme

{{uses}}

  \{$IFDEF OLD_UNIT_NAMES}
  Classes, Windows, SysUtils, *Character*, SyncObjs;
  \{$ELSE}
  System.Classes, Winapi.Windows, System.SysUtils, *System.Character*, 
System.SyncObjs;
  \{$ENDIF}

If condition OLD_UNIT_NAMES is not defined then compiler will require fully 
unit name. And identifier Character.IsLowSurrogate will not be defined unlike 
identifier System.Character.IsLowSurrogate


was (Author: antontramp):
Full unit name System.Character. This unit added in Thrift.Utils by scheme

{{uses}}
{{ \{$IFDEF OLD_UNIT_NAMES}}}
{{ Classes, Windows, SysUtils, *Character*, SyncObjs;}}
{{ \{$ELSE}}}
{{ System.Classes, Winapi.Windows, System.SysUtils, *System.Character*, 
System.SyncObjs;}}
{{ \{$ENDIF}}}

If condition OLD_UNIT_NAMES is not defined then compiler will require fully 
unit name. And identifier Character.IsLowSurrogate will not be defined unlike 
identifier System.Character.IsLowSurrogate

> Invalid compiler directive
> --
>
> Key: THRIFT-4461
> URL: https://issues.apache.org/jira/browse/THRIFT-4461
> Project: Thrift
>  Issue Type: Bug
>  Components: Delphi - Library
>Affects Versions: 0.11.0
> Environment: Delphi XE3
>Reporter: Anton Shchyrov
>Assignee: Jens Geyer
>Priority: Minor
>  Labels: delphi
> Attachments: Thrift.Utils.diff
>
>
> In module Thrift.Utils daclared two methods
> {{class function CharUtils.IsHighSurrogate( const c : Char) : Boolean;}}
> {{begin}}
> {{  \{$IF CompilerVersion < 23.0}}}
> {{  result := Character.IsHighSurrogate( c);}}
> {{  \{$ELSE}}}
> {{  result := c.IsHighSurrogate();}}
> {{  \{$IFEND}}}
> {{end;}}
> {{class function CharUtils.IsLowSurrogate( const c : Char) : Boolean;}}
> {{begin}}
> {{  \{$IF CompilerVersion < 23.0}}}
> {{  result := Character.IsLowSurrogate( c);}}
> {{  \{$ELSE}}}
> {{  result := c.IsLowSurrogate;}}
> {{  \{$IFEND}}}
> {{end;}}
> But methods Char.IsHighSurrogate()/Char.IsLowSurrogate() **appeared in Delphi 
> XE4. For Delphi XE4 variable CompilerVersion equal 25.
> In this way condition
> {{{$IF CompilerVersion < 23.0}}}
> may be changed to
> {{{$IF CompilerVersion < *25.0*}}}
> And access for unit *Character* may be determined through defiine symbol 
> *OLD_UNIT_NAMES*



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (THRIFT-4461) Invalid compiler directive

2018-01-19 Thread Anton Shchyrov (JIRA)

[ 
https://issues.apache.org/jira/browse/THRIFT-4461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16332593#comment-16332593
 ] 

Anton Shchyrov commented on THRIFT-4461:


Full unit name System.Character. This unit added in Thrift.Utils by scheme

{{uses}}
{{ \{$IFDEF OLD_UNIT_NAMES}}}
{{ Classes, Windows, SysUtils, *Character*, SyncObjs;}}
{{ \{$ELSE}}}
{{ System.Classes, Winapi.Windows, System.SysUtils, *System.Character*, 
System.SyncObjs;}}
{{ \{$ENDIF}}}

If condition OLD_UNIT_NAMES is not defined then compiler will require fully 
unit name. And identifier Character.IsLowSurrogate will not be defined unlike 
identifier System.Character.IsLowSurrogate

> Invalid compiler directive
> --
>
> Key: THRIFT-4461
> URL: https://issues.apache.org/jira/browse/THRIFT-4461
> Project: Thrift
>  Issue Type: Bug
>  Components: Delphi - Library
>Affects Versions: 0.11.0
> Environment: Delphi XE3
>Reporter: Anton Shchyrov
>Assignee: Jens Geyer
>Priority: Minor
>  Labels: delphi
> Attachments: Thrift.Utils.diff
>
>
> In module Thrift.Utils daclared two methods
> {{class function CharUtils.IsHighSurrogate( const c : Char) : Boolean;}}
> {{begin}}
> {{  \{$IF CompilerVersion < 23.0}}}
> {{  result := Character.IsHighSurrogate( c);}}
> {{  \{$ELSE}}}
> {{  result := c.IsHighSurrogate();}}
> {{  \{$IFEND}}}
> {{end;}}
> {{class function CharUtils.IsLowSurrogate( const c : Char) : Boolean;}}
> {{begin}}
> {{  \{$IF CompilerVersion < 23.0}}}
> {{  result := Character.IsLowSurrogate( c);}}
> {{  \{$ELSE}}}
> {{  result := c.IsLowSurrogate;}}
> {{  \{$IFEND}}}
> {{end;}}
> But methods Char.IsHighSurrogate()/Char.IsLowSurrogate() **appeared in Delphi 
> XE4. For Delphi XE4 variable CompilerVersion equal 25.
> In this way condition
> {{{$IF CompilerVersion < 23.0}}}
> may be changed to
> {{{$IF CompilerVersion < *25.0*}}}
> And access for unit *Character* may be determined through defiine symbol 
> *OLD_UNIT_NAMES*



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (THRIFT-1507) Maven can't download resource from central when behind a proxy and won't use local repository

2018-01-19 Thread Alexander Volanis (JIRA)

[ 
https://issues.apache.org/jira/browse/THRIFT-1507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16332579#comment-16332579
 ] 

Alexander Volanis commented on THRIFT-1507:
---

Possibly solved by the changes to implement THRIFT-4259. I will take a look at 
`sudo make install` to make sure it will work as expected.

> Maven can't download resource from central when behind a proxy and won't use 
> local repository
> -
>
> Key: THRIFT-1507
> URL: https://issues.apache.org/jira/browse/THRIFT-1507
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Library
>Affects Versions: 0.8
> Environment: Ubuntu 10.04 LTS, running in a VM in VMWare Player 
> hosted on Windows XP Pro which is behind a proxy server.
>Reporter: Mark Anderson
>Assignee: Jake Farrell
>Priority: Major
>  Labels: build, maven
>
> When 'make' enters lib/java, the build fails on the mvn.init target with:
> . . .
> [artifact:dependencies] [WARNING] Overriding profile: 
> 'maven-ant-tasks-repo-profile' (source: pom) with new instance from source: 
> pom
> [artifact:dependencies] Downloading: 
> org/slf4j/slf4j-api/1.5.8/slf4j-api-1.5.8.pom from repository central at 
> http://repo1.maven.org/maven2
> [artifact:dependencies] Error transferring file: Connection refused
> [artifact:dependencies] [WARNING] Unable to get resource 
> 'org.slf4j:slf4j-api:pom:1.5.8' from repository central 
> (http://repo1.maven.org/maven2): Error transferring file: Connection refused
> . . .
> This occurs for every dependency in the 'pom' artifact (on some files, the 
> error is "Connection timed out").
> The preceding target, mvn.ant.tasks.download, succeeds (the 
> maven-ant-tasks-2.1.3.jar file is sitting in the tools directory).
> I have added to build.xml:
> proxy.host=proxy1.domain.com
> proxy.port=80
> proxy.user=
> proxy.pass=
> proxy.enabled=true
> and to /etc/maven2/settings.xml:
>  
>   proxy1
>   true
>   http
>   proxy1.domain.com
>   80
>   localhost
> 
> Maven does not seem to be picking up the proxy.  If I manually download all 
> the resources and install them into my local repository (~/.m2/repository) as 
> suggested and re-run make, I still get the errors -- Maven doesn't try to use 
> the local repository.
> If I move the machine out from behind the firewall, everything works fine: 
> Maven downloads all the dependencies and the Java stuff is able to be built.  
> If I then put the machine back behind the firewall and run 'sudo make 
> install', Maven again tries to download the dependencies from central and 
> that, of course, fails.  It doesn't realize that all the dependencies have 
> been downloaded and the Java files have been compiled.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (THRIFT-3035) Thrift maven dependency misses org/slf4j/impl/StaticLoggerBinder which requires to run thrift client and server

2018-01-19 Thread Alexander Volanis (JIRA)

[ 
https://issues.apache.org/jira/browse/THRIFT-3035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16332574#comment-16332574
 ] 

Alexander Volanis commented on THRIFT-3035:
---

The slf4j choice of implementation should be given to the consumer of libthrift 
and not dictated by the dependency. IMHO the current dependency is correct in 
declaring the org.slf4j:slf4j-api as a non-optional compile dependency and 
leaving the implementation undefined. Slf4j bridge implementations for all 
popular logging backends are available.

> Thrift maven dependency misses  org/slf4j/impl/StaticLoggerBinder which 
> requires to run thrift client and server
> 
>
> Key: THRIFT-3035
> URL: https://issues.apache.org/jira/browse/THRIFT-3035
> Project: Thrift
>  Issue Type: Bug
>  Components: Deployment, Java - Library
>Reporter: Chamila Dilshan Wijayarathna
>Priority: Major
>
> I have added 
> 
> org.apache.thrift
> libthrift
> 0.9.2
> 
> to the pom.xml of my maven project, which uses thrift.
> At run time I'm getting a error as follows
> Exception in thread "main" java.lang.NoClassDefFoundError: 
> org/slf4j/impl/StaticLoggerBinder
>   at org.slf4j.LoggerFactory.getSingleton(LoggerFactory.java:223)
>   at org.slf4j.LoggerFactory.bind(LoggerFactory.java:120)
>   at org.slf4j.LoggerFactory.performInitialization(LoggerFactory.java:111)
>   at org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:269)
>   at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:242)
>   at rpc.node$Processor.(node.java:212)
>   at p2p.Controller.main(Controller.java:168)
> Caused by: java.lang.ClassNotFoundException: org.slf4j.impl.StaticLoggerBinder
>   at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
>   at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
>   at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
>   ... 7 more
> from node.java file which was the thrift auto generated file.
> I believe adding thrift maven dependency should add this dependency to the 
> project.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (THRIFT-3952) Upgrade from v1.5.8 to current version for slf4j

2018-01-19 Thread Alexander Volanis (JIRA)

[ 
https://issues.apache.org/jira/browse/THRIFT-3952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16332567#comment-16332567
 ] 

Alexander Volanis commented on THRIFT-3952:
---

Reducing the dependency on other projects is beneficial and providing a simple 
bridge API would go a long way to that goal.

> Upgrade from v1.5.8 to current version for slf4j
> 
>
> Key: THRIFT-3952
> URL: https://issues.apache.org/jira/browse/THRIFT-3952
> Project: Thrift
>  Issue Type: Dependency upgrade
>  Components: Java - Library
>Affects Versions: 0.9.3, 0.10.0
>Reporter: Tim Webex
>Priority: Minor
>
> Are slf4j-api-1.5.8.jar and slf4j-log4j12-1.5.8.jar intended to support the 
> older versions of Java? These are pretty old versions of slf4j.
> Can they be upgraded to the current version? 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[GitHub] thrift issue #1468: Thrift 4259: Thrift does not compile due to Ant Maven ta...

2018-01-19 Thread Alex-Vol
Github user Alex-Vol commented on the issue:

https://github.com/apache/thrift/pull/1468
  
I am marking JIRA items already fixed by this one as duplicates/related to 
and will update the description.


---


[jira] [Commented] (THRIFT-4294) Java Configure Fails for Ant >= 1.10

2018-01-19 Thread Alexander Volanis (JIRA)

[ 
https://issues.apache.org/jira/browse/THRIFT-4294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16332548#comment-16332548
 ] 

Alexander Volanis commented on THRIFT-4294:
---

Marking duplicate, solved by pending PR.

> Java Configure Fails for Ant >= 1.10
> 
>
> Key: THRIFT-4294
> URL: https://issues.apache.org/jira/browse/THRIFT-4294
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Library
>Affects Versions: 0.12.0
>Reporter: Mike Rettig
>Priority: Major
>  Labels: ant_build_system
>
> The configure step enables building the java lib if the ant version is >= 
> 1.7.  Unfortunately this check fails for ant 1.10 which is the latest 
> version. The library builds fine with 1.10.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[GitHub] thrift issue #1468: Thrift 4259: Thrift does not compile due to Ant Maven ta...

2018-01-19 Thread jeking3
Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1468
  
Once you have the description updated I will email the dev mailing list 
asking for more eyes.


---


[GitHub] thrift issue #1474: Recognize fbthrift TApplicationException codes

2018-01-19 Thread jparise
Github user jparise commented on the issue:

https://github.com/apache/thrift/pull/1474
  
I'm not affiliated with either project, but I work in an environment that 
uses multiple Thrift implementations, so interoperability is important to us. 
We're specifically interested in using some of these new codes (e.g. 
`LOADSHEDDING`) between services, and I think there's value in achieving error 
code parity. Likewise, if Apache Thrift had been the first to introduce these 
new error codes, I'd be making the same case for their inclusion in fbthrift 
and other implementations.

I don't know if it's important to establish a plan for "approving" new 
error codes going forward. When I wrote "guarantee no future conflicts" in the 
summary, I meant that these particular values (11, 12, 13) have already been 
effectively allocated by fbthrift, and adding them to Apache Thrift eliminates 
the chance that those indices are ever assigned to different, conflicting codes 
in this project.


---


[GitHub] thrift issue #1468: Thrift 4259: Thrift does not compile due to Ant Maven ta...

2018-01-19 Thread jeking3
Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1468
  
I don't necessarily mind additional organization however I think it would 
be a good idea for other more active Java folks to weigh in.  Also if this 
solves other Jira issues, listing them all in the description would be good.


---


[GitHub] thrift issue #1468: Thrift 4259: Thrift does not compile due to Ant Maven ta...

2018-01-19 Thread Alex-Vol
Github user Alex-Vol commented on the issue:

https://github.com/apache/thrift/pull/1468
  
I felt the need to make this organization like all the other java projects 
in Github. The files were moved for sure, splitting the cross-test files just 
makes them stand out. If you think it is a big deal I will just move the files 
back. Git will oblige.

At least now I know what was bugging AppVeyor. find_program will not return 
a .bat result even if I search for a .bat file if there is a plain named file 
in the same location. Somehow cmake/make is fine with executable "gradlew" in 
Windows but CTest simply fails with "bad command". A little help in the 
FindGradlew.cmake solved it.


---


Re: Is the Thrift serialization compatible both directions?

2018-01-19 Thread Jean Rodier
Regarding the last part which is inaccurate. It is not something that thrift 
should support?

It happen quite often that we want to update the components of a system one at 
a time without stoping the other components. Especially when the system must 
run 100% of the time. So new and old messages can live at the same time in the 
system. Old component working with messages as if they are all old version and 
new components working with them according to there real versions.

You said 
Is there any other way we can use Thrift that would not be the case?

Finally, do you see any interest to have that feature?

 Original message 
From: Randy Abernethy 
Date: 2018-01-18 9:18 PM (GMT-05:00)
To: dev@thrift.apache.org
Cc: u...@thrift.apache.org
Subject: Re: Is the Thrift serialization compatible both directions?

Taking this apart:

- Any new fields that you add should be optional.
I disagree, default requiredness with a default value works fine as well
(and is my preference if you are not interested in optimizing the field
away in procs that know about it). On the server side,if the default field
is there great, if not the default value is used. On the client side if the
field is known it is sent if not it is not.

- This means that any messages serialized by code using your "old" message
format can be parsed by your new generated code, as they won’t be missing
any required elements.
True and true with default requiredness as well.

- Similarly, messages created by your new code can be parsed by your old
code: old binaries simply ignore the new field when parsing.
True and true with default requiredness as well.

- However, the unknown fields are not discarded, and if the message is
later serialized, the unknown fields are serialized along with it — so if
the message is passed on to new code, the new fields are still available.
This is inaccurate. If you use Thrift "normally", when you deserialize, the
struct (message) will only contain the fields you know (in any
requiredness).

--Randy

On Thu, Jan 18, 2018 at 7:59 AM, Jean Rodier <
jean.rod...@tatacommunications.com> wrote:

> Hi,
>
> Is this statement true, especially the last part?
>
> Any new fields that you add should be optional. This means that any
> messages serialized by code using your "old" message format can be parsed
> by your new generated code, as they won’t be missing any required elements.
> Similarly, messages created by your new code can be parsed by your old
> code: old binaries simply ignore the new field when parsing. However, the
> unknown fields are not discarded, and if the message is later serialized,
> the unknown fields are serialized along with it — so if the message is
> passed on to new code, the new fields are still available.
>
> Jean
>


[GitHub] thrift issue #1468: Thrift 4259: Thrift does not compile due to Ant Maven ta...

2018-01-19 Thread jeking3
Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1468
  
I don't think folks are going to be too happy about having many levels of 
new empty directories:

crossTest/java/org/apache/thrift/test
main/java/org/apache/thrift

Every .java file moved.  Ouch?


---


[jira] [Commented] (THRIFT-4461) Invalid compiler directive

2018-01-19 Thread Jens Geyer (JIRA)

[ 
https://issues.apache.org/jira/browse/THRIFT-4461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16331889#comment-16331889
 ] 

Jens Geyer commented on THRIFT-4461:


{quote}

And access for unit Character may be determined through defiine symbol 
OLD_UNIT_NAMES

{quote}

 

Why?

> Invalid compiler directive
> --
>
> Key: THRIFT-4461
> URL: https://issues.apache.org/jira/browse/THRIFT-4461
> Project: Thrift
>  Issue Type: Bug
>  Components: Delphi - Library
>Affects Versions: 0.11.0
> Environment: Delphi XE3
>Reporter: Anton Shchyrov
>Assignee: Jens Geyer
>Priority: Minor
>  Labels: delphi
> Attachments: Thrift.Utils.diff
>
>
> In module Thrift.Utils daclared two methods
> {{class function CharUtils.IsHighSurrogate( const c : Char) : Boolean;}}
> {{begin}}
> {{  \{$IF CompilerVersion < 23.0}}}
> {{  result := Character.IsHighSurrogate( c);}}
> {{  \{$ELSE}}}
> {{  result := c.IsHighSurrogate();}}
> {{  \{$IFEND}}}
> {{end;}}
> {{class function CharUtils.IsLowSurrogate( const c : Char) : Boolean;}}
> {{begin}}
> {{  \{$IF CompilerVersion < 23.0}}}
> {{  result := Character.IsLowSurrogate( c);}}
> {{  \{$ELSE}}}
> {{  result := c.IsLowSurrogate;}}
> {{  \{$IFEND}}}
> {{end;}}
> But methods Char.IsHighSurrogate()/Char.IsLowSurrogate() **appeared in Delphi 
> XE4. For Delphi XE4 variable CompilerVersion equal 25.
> In this way condition
> {{{$IF CompilerVersion < 23.0}}}
> may be changed to
> {{{$IF CompilerVersion < *25.0*}}}
> And access for unit *Character* may be determined through defiine symbol 
> *OLD_UNIT_NAMES*



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Assigned] (THRIFT-4462) Incorrect first line in Console

2018-01-19 Thread Jens Geyer (JIRA)

 [ 
https://issues.apache.org/jira/browse/THRIFT-4462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jens Geyer reassigned THRIFT-4462:
--

Assignee: Jens Geyer

> Incorrect first line in Console
> ---
>
> Key: THRIFT-4462
> URL: https://issues.apache.org/jira/browse/THRIFT-4462
> Project: Thrift
>  Issue Type: Bug
>  Components: Delphi - Library
>Affects Versions: 0.11.0
>Reporter: Anton Shchyrov
>Assignee: Jens Geyer
>Priority: Minor
> Attachments: Thrift.Console.patch
>
>
> Method Console.Write/WriteLine in class TGUIConsole after called method 
> *Write* and clear log duplicates current message
> {{ChangeConsole(TGUIConsole.Create(Memo1.Lines));}}
> {{Console.Write('String');  // Set internal FLineBreak to False}}
> {{Memo1.Lines.Clear;}}
> {{Console.Write('Some String');  // Log have "Some StringSome String"}}
> Reason in method 
> {{procedure TGUIConsole.InternalWrite(const S: string; bWriteLine: Boolean);}}
> {{var}}
> {{  idx : Integer;}}
> {{begin}}
> {{  if FLineBreak then}}
> {{  begin}}
> {{    FMemo.Add( S );}}
> {{  end else}}
> {{  begin}}
> {{    idx := FMemo.Count - 1;}}
> {{    if idx < 0 then}}
> {{    begin}}
> {{      FMemo.Add( S );}}
> {{    end;}}
> {{    FMemo[idx] := FMemo[idx] + S;}}
> {{  end;}}
> {{  FLineBreak := bWriteLine;}}
> {{end;}}
> If FMemo.Count = 0 then idx = -1 and string added to log. But next line
> {{FMemo[idx] := FMemo[idx] + S;}}
> repeats the added string. should be
>     if idx < 0 then
>     begin
>       FMemo.Add( S );
>     end *else*
>       FMemo[idx] := FMemo[idx] + S;



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[GitHub] thrift issue #1474: Recognize fbthrift TApplicationException codes

2018-01-19 Thread Jens-G
Github user Jens-G commented on the issue:

https://github.com/apache/thrift/pull/1474
  
I see the point but I'm not sure if Inunderstzand it right. Who doies what 
before we add new codes? We ask FB? Or they ask us? And what ist your plan to 
convince FB that they have to ask us?


---