Re: [fpc-pascal] Reading and writing char
In our previous episode, Thomas Young said: > For some reason I'm not able to read and write ascii characters above > ascii 127 with FPC. Can someone explain this to me? This is very logical, since ASCII only defines +/- 127 chars. The upper 128 were used for vendor specific characters (aka codepages), which were later somewhat standarized in ISO norms. So the first step is what characters you actualy expect above 127. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] freetype unit + unicode
On Wed, 5 Oct 2011, David Emerson wrote: On Tue 4 Oct 2011, michael.vancann...@wisa.be wrote: If you need some UTF8 extensions to the freetype unit, feel free to make some suggestions, and we'll see what we can do. When the unit was made, unicode support was a thing of the distant future. (a future which of course crept up on us faster than we imagined) attached is a patch, which (if applied correctly...) seems to work, yay! Here is a picture: http://david9.freepgs.com/i/spline-unicode-text.png I copied a few UTF8 string functions from the LCLProc unit, so that is kind of sloppy but there it is. I'm not sure if analogs exist within fpc. Surprisingly little needed to be changed! Yes, but the problem with this is that it only works with UTF-8 now. So I would have preferred it if you had created an overloaded or even differently named version of the existing functions, and left the existing functions intact. The way it is now, we'd force everyone to use UTF-8. I'll see if I can modify the patch. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] freetype unit + unicode
On Thu 6 Oct 2011, michael.vancann...@wisa.be wrote: > On Wed, 5 Oct 2011, David Emerson wrote: > > On Tue 4 Oct 2011, michael.vancann...@wisa.be wrote: > >> If you need some UTF8 extensions to the freetype unit, feel free to make > >> some suggestions, and we'll see what we can do. > > > > I copied a few UTF8 string functions from the LCLProc unit, so that is kind > > of sloppy but there it is. I'm not sure if analogs exist within fpc. > > Yes, but the problem with this is that it only works with UTF-8 now. indeed my inexperience shows (and american mindset!) > So I would have preferred it if you had created an overloaded or even > differently named version of the existing functions, and left the existing > functions intact. The way it is now, we'd force everyone to use UTF-8. > > I'll see if I can modify the patch. > > Michael. I'd be happy to help in this regard if you want to give me some sort of instructions to go by. Now that you bring up the issue, numerous solutions come to mind. Of course the task is not that big, but I'm eager to help if it would save you any trouble (although tonight it's past my bedtime now...) ~David. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Reading and writing char
Thank you for the article. It was very helpful.
Why is it I can read and write a string that contains characters in the upper
128 but can't read & write them as individual char?
Specifically I need to read the copyright (169), trademark (170) and
registration (168) characters. Any suggestions on how I can do this?
Thomas Young
cell: 330-256-7064
mobile email: tygraph...@me.com
On Oct 6, 2011, at 2:23 AM, David Emerson wrote:
> On Wed 5 Oct 2011, Thomas Young wrote:
>> Hi,
>>
>> I'm trying to read and write ascii characters using FPC. I had no problems
>> doing this years ago with Think Pascal & Code Warrior.
>>
>> For some reason I'm not able to read and write ascii characters above ascii
>> 127 with FPC. Can someone explain this to me?
>>
>> Thanks in advance!
>
> The world has changed, and globalization has reached your computer. Your
> computer is almost definitely using a different character set today than it
> was
> back in those days long ago. read this:
> http://www.joelonsoftware.com/articles/Unicode.html
> The Absolute Minimum Every Software Developer Absolutely, Positively Must
> Know
> About Unicode and Character Sets (No Excuses!)
>
> ~D.
>
>>
>> Using this code:
>> for i:= 33 to 226 do
>> writeln('Character: ', chr(i), ' Ascii value: ', i:1);
>>
>> Character: ! Ascii value: 33
>> Character: " Ascii value: 34
>> Character: # Ascii value: 35
>> Character: $ Ascii value: 36
>> Character: % Ascii value: 37
>> Character: & Ascii value: 38
>> Character: ' Ascii value: 39
>> Character: ( Ascii value: 40
>> Character: ) Ascii value: 41
>> Character: * Ascii value: 42
>> Character: + Ascii value: 43
>> Character: , Ascii value: 44
>> Character: - Ascii value: 45
>> Character: . Ascii value: 46
>> Character: / Ascii value: 47
>> Character: 0 Ascii value: 48
>> Character: 1 Ascii value: 49
>> Character: 2 Ascii value: 50
>> Character: 3 Ascii value: 51
>> Character: 4 Ascii value: 52
>> Character: 5 Ascii value: 53
>> Character: 6 Ascii value: 54
>> Character: 7 Ascii value: 55
>> Character: 8 Ascii value: 56
>> Character: 9 Ascii value: 57
>> Character: : Ascii value: 58
>> Character: ; Ascii value: 59
>> Character: < Ascii value: 60
>> Character: = Ascii value: 61
>> Character: > Ascii value: 62
>> Character: ? Ascii value: 63
>> Character: @ Ascii value: 64
>> Character: A Ascii value: 65
>> Character: B Ascii value: 66
>> Character: C Ascii value: 67
>> Character: D Ascii value: 68
>> Character: E Ascii value: 69
>> Character: F Ascii value: 70
>> Character: G Ascii value: 71
>> Character: H Ascii value: 72
>> Character: I Ascii value: 73
>> Character: J Ascii value: 74
>> Character: K Ascii value: 75
>> Character: L Ascii value: 76
>> Character: M Ascii value: 77
>> Character: N Ascii value: 78
>> Character: O Ascii value: 79
>> Character: P Ascii value: 80
>> Character: Q Ascii value: 81
>> Character: R Ascii value: 82
>> Character: S Ascii value: 83
>> Character: T Ascii value: 84
>> Character: U Ascii value: 85
>> Character: V Ascii value: 86
>> Character: W Ascii value: 87
>> Character: X Ascii value: 88
>> Character: Y Ascii value: 89
>> Character: Z Ascii value: 90
>> Character: [ Ascii value: 91
>> Character: \ Ascii value: 92
>> Character: ] Ascii value: 93
>> Character: ^ Ascii value: 94
>> Character: _ Ascii value: 95
>> Character: ` Ascii value: 96
>> Character: a Ascii value: 97
>> Character: b Ascii value: 98
>> Character: c Ascii value: 99
>> Character: d Ascii value: 100
>> Character: e Ascii value: 101
>> Character: f Ascii value: 102
>> Character: g Ascii value: 103
>> Character: h Ascii value: 104
>> Character: i Ascii value: 105
>> Character: j Ascii value: 106
>> Character: k Ascii value: 107
>> Character: l Ascii value: 108
>> Character: m Ascii value: 109
>> Character: n Ascii value: 110
>> Character: o Ascii value: 111
>> Character: p Ascii value: 112
>> Character: q Ascii value: 113
>> Character: r Ascii value: 114
>> Character: s Ascii value: 115
>> Character: t Ascii value: 116
>> Character: u Ascii value: 117
>> Character: v Ascii value: 118
>> Character: w Ascii value: 119
>> Character: x Ascii value: 120
>> Character: y Ascii value: 121
>> Character: z Ascii value: 122
>> Character: { Ascii value: 123
>> Character: | Ascii value: 124
>> Character: } Ascii value: 125
>> Character: ~ Ascii value: 126
>> Character:Ascii value: 127
>> Character: ? Ascii value: 128
>> Character: ? Ascii value: 129
>> Character: ? Ascii value: 130
>> Character: ? Ascii value: 131
>> Character: ? Ascii value: 132
>> Character: ? Ascii value: 133
>> Character: ? Ascii value: 134
>> Character: ? Ascii value: 135
>> Character: ? Ascii value: 136
>> Character: ? Ascii value: 137
>>
>> truncated for brevity.
>>
>>
>> Thomas Young
>> mobile ema
Re: [fpc-pascal] Reading and writing char
On Thu, October 6, 2011 10:21, Thomas Young wrote:
>
> Thank you for the article. It was very helpful.
>
> Why is it I can read and write a string that contains characters in the
> upper 128 but can't read & write them as individual char?
This is most probably due to the fact that your platform uses/requires a
multi-byte encoding of these characters nowadays (probably UTF-8) as
opposed to the platform / version you used those 'years ago' with
ThinkPascal. You need a different way for referring to the particular
characters than you used in the past, or you need to translate the
original meaning (based on a particular character set like Mac Roman you
may have used in the past).
> Specifically I need to read the copyright (169), trademark (170) and
> registration (168) characters. Any suggestions on how I can do this?
If you specifically need these, put those characters as constant strings
in your code and use those strings. Also, make sure to specify the
encoding used for your source code directly in the source code (using the
respective compiler directive or the UTF-8 marker) to avoid possible wrong
interpretation.
Tomas
>
> On Oct 6, 2011, at 2:23 AM, David Emerson wrote:
>
>> On Wed 5 Oct 2011, Thomas Young wrote:
>>> Hi,
>>>
>>> I'm trying to read and write ascii characters using FPC. I had no
>>> problems
>>> doing this years ago with Think Pascal & Code Warrior.
>>>
>>> For some reason I'm not able to read and write ascii characters above
>>> ascii
>>> 127 with FPC. Can someone explain this to me?
>>>
>>> Thanks in advance!
>>
>> The world has changed, and globalization has reached your computer. Your
>> computer is almost definitely using a different character set today than
>> it was
>> back in those days long ago. read this:
>> http://www.joelonsoftware.com/articles/Unicode.html
>> The Absolute Minimum Every Software Developer Absolutely, Positively
>> Must Know
>> About Unicode and Character Sets (No Excuses!)
>>
>> ~D.
>>
>>>
>>> Using this code:
>>> for i:= 33 to 226 do
>>> writeln('Character: ', chr(i), ' Ascii value: ', i:1);
>>>
>>> Character: ! Ascii value: 33
>>> Character: " Ascii value: 34
>>> Character: # Ascii value: 35
>>> Character: $ Ascii value: 36
.
.
>>> Character: ~ Ascii value: 126
>>> Character:Ascii value: 127
>>> Character: ? Ascii value: 128
>>> Character: ? Ascii value: 129
>>> Character: ? Ascii value: 130
>>> Character: ? Ascii value: 131
>>> Character: ? Ascii value: 132
>>> Character: ? Ascii value: 133
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Git line endings leading to patch problems - was [Semi-OT] Git format patches don't seem to work
On 4-10-2011 14:41, Reinier Olislagers wrote: > On 4-10-2011 13:14, Marco van de Voort wrote: >> In our previous episode, Reinier Olislagers said: >>> Having some trouble creating patches that actually work. >>> (On Windows) >>> I've been using git to get FPC trunk and >>> git diff --no-prefix > %temp%\mypatch.diff >> I don't know about GIT, but some tips: >> >> 1. Play with lineending. (I use cygwin's dos2unix and unix2dos to convert) Ok, I've looked at it some more: Example: packages\fcl-extra\src\win\ServiceManager.pas svn: via web: http://svn.freepascal.org/svn/fpc/trunk/packages/fcl-extra/src/win/ServiceManager.pas => Unix line endings Local svn: svn proplist -v packages\fcl-extra\src\win\ServiceManager.pas svn:eol-style native so: => WINDOWS LINE ENDINGS Therefore patch.exe on Windows probably works Git: https://github.com/graemeg/freepascal/raw/7026b7669fd422f88ffe33174dac1725c0295427/packages/fcl-extra/src/win/ServiceManager.pas => Unix line endings via git pull etc => Unix line endings not surprising... Seems the SVN client is converting line endings to my native format. Seems also that there is no way to get git to convert remote LF to local CRLF... Should I give up on git and just switch to SVN? I'm sure some more knowledgeable/alert person will have a suitable answer! Thanks, Reinier ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Git line endings leading to patch problems - was [Semi-OT] Git format patches don't seem to work
06.10.2011 16:37, Reinier Olislagers пишет: On 4-10-2011 14:41, Reinier Olislagers wrote: On 4-10-2011 13:14, Marco van de Voort wrote: In our previous episode, Reinier Olislagers said: Having some trouble creating patches that actually work. (On Windows) I've been using git to get FPC trunk and git diff --no-prefix> %temp%\mypatch.diff I don't know about GIT, but some tips: 1. Play with lineending. (I use cygwin's dos2unix and unix2dos to convert) Ok, I've looked at it some more: Example: packages\fcl-extra\src\win\ServiceManager.pas svn: via web: http://svn.freepascal.org/svn/fpc/trunk/packages/fcl-extra/src/win/ServiceManager.pas => Unix line endings Local svn: svn proplist -v packages\fcl-extra\src\win\ServiceManager.pas svn:eol-style native so: => WINDOWS LINE ENDINGS Therefore patch.exe on Windows probably works Git: https://github.com/graemeg/freepascal/raw/7026b7669fd422f88ffe33174dac1725c0295427/packages/fcl-extra/src/win/ServiceManager.pas => Unix line endings via git pull etc => Unix line endings not surprising... Seems the SVN client is converting line endings to my native format. Seems also that there is no way to get git to convert remote LF to local CRLF... Should I give up on git and just switch to SVN? I'm sure some more knowledgeable/alert person will have a suitable answer! Thanks, Reinier ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal there is git config option "core.autocrlf" try to use it ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Git line endings leading to patch problems - was [Semi-OT] Git format patches don't seem to work
On 6-10-2011 16:56, Alex Shishkin wrote: > 06.10.2011 16:37, Reinier Olislagers пишет: >> On 4-10-2011 14:41, Reinier Olislagers wrote: >>> On 4-10-2011 13:14, Marco van de Voort wrote: In our previous episode, Reinier Olislagers said: > Having some trouble creating patches that actually work. > (On Windows) > I've been using git to get FPC trunk and > git diff --no-prefix> %temp%\mypatch.diff I don't know about GIT, but some tips: 1. Play with lineending. (I use cygwin's dos2unix and unix2dos to convert) >> Ok, I've looked at it some more: >> Example: >> packages\fcl-extra\src\win\ServiceManager.pas >> >> svn: >> via web: >> http://svn.freepascal.org/svn/fpc/trunk/packages/fcl-extra/src/win/ServiceManager.pas >> >> => Unix line endings >> Local svn: >> svn proplist -v packages\fcl-extra\src\win\ServiceManager.pas >>svn:eol-style >> native >> so: >> => WINDOWS LINE ENDINGS >> Therefore patch.exe on Windows probably works >> >> Git: >> https://github.com/graemeg/freepascal/raw/7026b7669fd422f88ffe33174dac1725c0295427/packages/fcl-extra/src/win/ServiceManager.pas >> >> => Unix line endings >> via git pull etc >> => Unix line endings >> not surprising... >> >> Seems the SVN client is converting line endings to my native format. >> >> Seems also that there is no way to get git to convert remote LF to local >> CRLF... >> >> >> Should I give up on git and just switch to SVN? >> >> I'm sure some more knowledgeable/alert person will have a suitable >> answer! >> >> Thanks, >> Reinier >> > there is git config option "core.autocrlf" try to use it Thanks Alex, I already fiddled with that. I'll try again with core.autocrlf set to true and false to make sure it doesn't work... ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Git line endings leading to patch problems - was [Semi-OT] Git format patches don't seem to work
06.10.2011 18:59, Reinier Olislagers пишет: Thanks Alex, I already fiddled with that. I'll try again with core.autocrlf set to true and false to make sure it doesn't work... ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal not "true" not "false", but "input". Read this if have not yet : http://progit.org/book/ch7-1.html http://help.github.com/line-endings/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Git line endings leading to patch problems - was [Semi-OT] Git format patches don't seem to work
On 06/10/2011, Reinier Olislagers wrote: > > Git: > https://github.com/graemeg/freepascal/raw/7026b7669fd422f88ffe33174dac1725c0295427/packages/fcl-extra/src/win/ServiceManager.pas > => Unix line endings > via git pull etc > => Unix line endings > not surprising... > > Seems the SVN client is converting line endings to my native format. Don't be so quick to blame the tool, rather learn how to use the tool! If you want Git to convert EOL characters to your native platform, then tell it to do so during the Git installation (which you clearly skipped or didn't understand the options), or specify it later as a global or per repository option (normally before a 'git clone' process). Here it show the option you somehow skipped to notice in the Git installation: http://opensoft.homeip.net:8080/~graemeg/msysgit-1.png To find out more about the core.autocrlf option look it the help: git help config then search for 'core.autocrlf' -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Git line endings leading to patch problems - was [Semi-OT] Git format patches don't seem to work
On 06/10/2011, Reinier Olislagers wrote: > > Thanks Alex, I already fiddled with that. I'll try again with > core.autocrlf set to true and false to make sure it doesn't work... As far as I know, Git will only do the conversion when you clone a new repository, or when you pull new changes. If you had the setting wrong at the time you did the clone, the problem is on you. Simply change the setting, and get another clone (use --depth if you don't want a full clone again) Alternatively, you might be able to get away with only specifying the following command line option with you 'git diff' command. I use this if I made a cloned repository under Linux, but share that repository with a Windows VM session (thus not cloned from inside the VM). --ignore-space-at-eol 'git help diff' will give you more such options. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Git line endings leading to patch problems - was [Semi-OT] Git format patches don't seem to work
06.10.2011 19:15, Graeme Geldenhuys пишет: As far as I know, Git will only do the conversion when you clone a new repository, or when you pull new changes. If you had the setting wrong at the time you did the clone, the problem is on you. Simply change the setting, and get another clone (use --depth if you don't want a full clone again) No, git do conversion on checkout and commit. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] What about complex numbers?
Thanks! I recently downloaded the rtl source code, and confirmed this 2011/10/5 Jeppe Græsdal Johansen > Den 06-10-2011 00:30, Carlos Avila skrev: > > Hello > Is complex number arithmetic possible in FPC? Another post recommends use > unit so named ucomplex, but i can't find any detailed information of this in > the documentation. But, amazingly, i sucessfully probed this small program: > > PROGRAM DUMMY; > > USES UCOMPLEX; > > VAR > > x,y, z, w: COMPLEX; > > BEGIN > x := 8+i*7; > y := 4-5*i; > z := x+y; > w := x*y > > END. > > This program compile and run right, but why? I need to know about > anything subroutines that works with complex numbers. It is posibble to > write math operations like FORTRAN? > > Thanks > > The unit ucomplex is part of the rtl. It uses simple operator overloading > to add a pretty useful complex type into your program. You can use it(pretty > much) as any other type. It's not any special type, it's just a record where > all the operators got overloaded > > Try to open the source code for that unit, and you'll see how beautifully > simple it is :) > > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-pascal > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Git line endings leading to patch problems - was [Semi-OT] Git format patches don't seem to work
On 6-10-2011 17:07, Graeme Geldenhuys wrote: > On 06/10/2011, Reinier Olislagers wrote: >> >> Git: >> https://github.com/graemeg/freepascal/raw/7026b7669fd422f88ffe33174dac1725c0295427/packages/fcl-extra/src/win/ServiceManager.pas >> => Unix line endings >> via git pull etc >> => Unix line endings >> not surprising... >> >> Seems the SVN client is converting line endings to my native format. Thanks for the clear explanation. > Don't be so quick to blame the tool, rather learn how to use the tool! Not really, I did suggest that smarter users than me might have a solution... ;) > If you want Git to convert EOL characters to your native platform, > then tell it to do so during the Git installation (which you clearly > skipped or didn't understand the options), or specify it later as a > global or per repository option (normally before a 'git clone' > process). Thanks, that matches with what I found out. > > Here it show the option you somehow skipped to notice in the Git installation: > http://opensoft.homeip.net:8080/~graemeg/msysgit-1.png Did see that, thought about it & obviously picked the wrong one ;) > To find out more about the core.autocrlf option look it the help: > git help config > then search for 'core.autocrlf' Yep, had seen that, but it wasn't too clear to a git newb like me though. Still, I've been finding out more - by trial and error ;) I had supposed that FPC stored its text files in CRLF format but obviously both the Git and SVN repositories contain LF data. I'll get back to the list when necessary. Thanks for the help. thanks, Reinier ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Git line endings leading to patch problems - was [Semi-OT] Git format patches don't seem to work
On 6-10-2011 17:04, Alex Shishkin wrote: > 06.10.2011 18:59, Reinier Olislagers пишет: >> Thanks Alex, I already fiddled with that. I'll try again with >> core.autocrlf set to true and false to make sure it doesn't work... >> >> > not "true" not "false", but "input". Read this if have not yet : > http://progit.org/book/ch7-1.html http://help.github.com/line-endings/ Thanks Alex, that's a fairly clear explanation. Reinier ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Git line endings leading to patch problems - was [Semi-OT] Git format patches don't seem to work
On 6-10-2011 17:04, Alex Shishkin wrote: > 06.10.2011 18:59, Reinier Olislagers пишет: >> Thanks Alex, I already fiddled with that. I'll try again with >> core.autocrlf set to true and false to make sure it doesn't work... >> > not "true" not "false", but "input". Read this if have not yet : > http://progit.org/book/ch7-1.html http://help.github.com/line-endings/ Alex & the rest, seems I'm doing something wrong when using input: rem go to right directory: cd /d c:\development\fpc\ rem get rid of any gunk there: rmdir /s /q source rem set autocrlf to input for entire git system git config --global core.autocrlf input rem check setting - yes, input: git config --global core.autocrlf input mkdir c:\development\fpc\source cd /d c:\development\fpc\source git clone --depth 5 git://github.com/graemeg/freepascal.git . rem check situation here - yes, still input: git config core.autocrlf input rem now use notepad++ to open a file: npp packages\fcl-extra\src\win\ServiceManager.pas !!!notepad++ shows it has Unix line endings Could be that I'm misinterpreting the docs/sites, but isn't input supposed to convert the LFs in the repository to CRLFs? Tried again using core.autocrlf true, this does result in Windows line endings. Creating a patch using git diff --no-prefix gives Unix line endings - as expected, really. So while it could be used, I'd have to remember to run unix2dos over it - that is, if people expect a Windows patch ( Am I doing something stupid with autocrlf input? Thanks, Reinier ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Git line endings leading to patch problems - was [Semi-OT] Git format patches don't seem to work
06.10.2011 22:41, Reinier Olislagers пишет: On 6-10-2011 17:04, Alex Shishkin wrote: 06.10.2011 18:59, Reinier Olislagers пишет: Thanks Alex, I already fiddled with that. I'll try again with core.autocrlf set to true and false to make sure it doesn't work... not "true" not "false", but "input". Read this if have not yet : http://progit.org/book/ch7-1.html http://help.github.com/line-endings/ Alex& the rest, seems I'm doing something wrong when using input: rem go to right directory: cd /d c:\development\fpc\ rem get rid of any gunk there: rmdir /s /q source rem set autocrlf to input for entire git system git config --global core.autocrlf input rem check setting - yes, input: git config --global core.autocrlf input mkdir c:\development\fpc\source cd /d c:\development\fpc\source git clone --depth 5 git://github.com/graemeg/freepascal.git . rem check situation here - yes, still input: git config core.autocrlf input rem now use notepad++ to open a file: npp packages\fcl-extra\src\win\ServiceManager.pas !!!notepad++ shows it has Unix line endings Could be that I'm misinterpreting the docs/sites, but isn't input supposed to convert the LFs in the repository to CRLFs? Tried again using core.autocrlf true, this does result in Windows line endings. Creating a patch using git diff --no-prefix gives Unix line endings - as expected, really. So while it could be used, I'd have to remember to run unix2dos over it - that is, if people expect a Windows patch ( Am I doing something stupid with autocrlf input? Thanks, Reinier ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal Sorry, my mistake. In your situation "autocrlf yes" should be used. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
