text:
Transportation Deployment Casebook/2023/TGV

Introduction
TGV is a high-speed rail network developed in France that connects major domestic and international cities in Belgium, Germany, UK, Italy, Netherlands, Luxembourg and Switzerland over the span of 2696 kilometres. Opened to the public in September 1981 between the two major cities of Paris and Lyon, TGV is one of the first high-speed rails in Europe and its success has prompted other countries around Europe to develop their own high-speed rail network.

The launch of the Japanese Shinkansen prompted the development of the TGV program in the late 1960s. This was because Shinkansen aimed to address the similar issue France was facing in terms of the domestic travel between major cities, and the Japanese had succeeded by significantly reducing the time and energy consumed between the passenger transportation between Tokyo and Osaka.

The French also faced the limitations on the existing modes to address large geographical separation between cities. TGV aimed to address the main market of passengers travelling intercities by prioritising its main advantages over the other modes of transport. This included improved travel time compared to cars and conventional rail, while being more accessible and consuming less energy in comparison to air travels. This project also served to provide the citizens with more free time by reducing the travel time.

Today, TGV is one of the fastest commercial trains in the world, enabling fast and efficient intercity and international travels to and from France. Since its opening, the tracks have been regularly improved and new lines have been built to expand the network. While its cost-feasibility is debated even until today, it can be safely stated that the innovation of TGV had made a significant contribution to the innovation of passenger transportation in Europe.

Existing Modes
Before the TGV was opened, there were limited options to travel intercities, mainly between the metropolitan capital Paris and the second and third largest cities in France, Marseille and Lyon respectively which both were located towards the south-east of the country. The transport options included travelling by road, conventional rail and aeroplane. Since the opening of TGV had covered between Paris and Lyon, the comparison in travel time is only to cover between these two cities.

The travel time between Paris and Lyon by road and conventional rail was similar at around 4 hours 30 minutes and 4 hours respectively. Travelling by automobile came at an additional disadvantage of having to pay for their own petrol in Europe where the petrol was highly taxed. Travelling by conventional rail meant that passengers did not have to worry about refuelling or parking in busy cities, however, some passengers preferred the versatility and flexibility that came with a private automobile. Flying between the two cities significantly reduced travel time to 75 minutes, and passengers were required to board and alight at the respective airport.

Limitations of existing modes
Prior to the opening of TGV, France was experiencing growth in intercity travels, and this increasingly put a strain on the existing modes above. Apart from the issue of high-taxed petrol in Europe mentioned previously, automobile travel increased road traffic and parking demands in the already populated cities. Conventional rail faced its limitations on its near-full capacity, and the infrastructures were regarded as outdated. The most probable largest limitation that the above two modes faced was the long commute, which could instead be spent more practically if they could commute faster.

Flying also had its limitations in terms of its versatility. Commuters were required to travel to the airport and check in which added to the overall time of commute. Moreover, relying on flying to address the high demands of intercity travel was inefficient because operating aircraft consumed considerably larger energy compared to the previous modes mentioned. Hence, a mode of transport that could efficiently transport passengers intercities while being accessible and low energy consuming was required.

Innovation
To fulfil the design requirements outlined above, TGV have made a number of changes and innovations from the previous conventional rail design. There was a development in both the hardware and software of the mode.

There were significant physical changes to the train itself to make it more aerodynamic and less energy consuming. The first and the most obvious to the eye was the aerodynamic styling of the nose which reduced the drag coefficient and effectively enabled the train to go at a higher speed with less air resistance.

The articulation of the TGV trainset was significantly altered from the previous design of conventional rail. The new design implemented an axle between the cars instead of each car having its own axle on back and front. This effectively meant that two cars were semi-permanently attached to each other on the same axle, acting as a trailer for the car in front. Moreover, this design enabled the train to sit lower to the ground improving aerodynamics. These factors led to reduced number of axles which meant lighter weight of the train, ultimately leading to reduced energy consumption. Apart from its energy consumption, this articulation also improved the ride smoothness and travelling between the cars by allowing to couple dampers between the cars, compared to the relatively rough ride quality of the conventional rail which had limited dampers.

The innovation in the development of TGV was also evident in its signalling functions. Instead of lineside signals used in conventional rail, TGV had its signalling information transferred by the rails as lineside signals were unsuitable to read for high speed running.

Early market development
In the development stages of TGV, the primary market was identified as the passengers who travel through the most congested and inconvenient route. This was chosen as the commuters who travel between Paris and Lyon, which were one of the largest cities in France and together accounted for approximately 40% of the nation’s population at the time. Furthermore, the roads between these cities were generally congested due to the high volume of traffic. The existing market included but was not limited to commuters on business trips and vacation. The high-speed rail network intended to compete with flying which also served as a high-speed alternative.

The functional enhancement of the existing modes played a significant role in TGV’s market development. There were clear limitations on the existing modes as detailed in above sections, and TGV aimed to grant the accessibility of conventional rail while providing commute time that is comparable to flying. In terms of the comparison with the aeroplanes, which was its main competitor, TGV granted ease of transfers to connect the passengers to different parts of the city more efficiently than transferring at airports, which was located on the outskirts of the city. These all contributed to the reduction of door to door travel times and increased practicality which the existing market had desired. In essence, the market development of TGV aimed to draw in the commuters who desired fast travels by aeroplane as well the market who desired accessibility, lower costs and energy consumption which was provided by conventional rail and automobiles.

Policy in the birthing phase
The government of France employed various policies both during development and early stages of TGV. The first and most notable policy was national champions policy, which subsidised research and development of new technologies and aimed to make marketable innovations which could seek profit in the future. TGV was developed in the same period as other French projects such as the Concorde airliner and Ariane 1 rocket.

The TGV program was however considered a technological dead end during its early stages of development and did not receive any government funding until its decision to utilise the existing railway infrastructures. Rather than building new tracks and infrastructures for TGV from the beginning which would be deemed expensive, this policy intended to gradually build more infrastructures and new rail lines opening in multiple sections and eventually into its own exclusive rail infrastructure.

This decision was also influenced by the financial issues Japan had faced in its opening of the Shinkansen, which had built its exclusive infrastructure from the beginning. TGV had also differed from Shinkansen in addressing geographical constraints of developing tracks. Rather than building tracks in a near-straight line in Shinkansen using dozens of tunnels to bypass the mountainous terrain, TGV tracks had been built around the topography to reduce the cost of earthworks. This financial policy which was learnt from Japan had made the project more financially stable in its birthing phase.

The ticketing price policy was employed from the opening of TGV by SNCF, the national owned operator of TGV who also controlled most of the rail networks. This included a demand-based model which had been adopted previously by airlines, where the ticket prices increased during peak seasons, day of the week or time of the day. It also varied depending on the destination of the route. This was again a financial policy to maximise the profit of the mode, and was first in Europe to apply it to train timetables.

Another ticketing policy at its opening was setting the cost of the tickets the same as in conventional rail on the parallel line to TGV to encourage ridership. This policy aimed to set a message to the public that high-speed rail was not a premium service targeted at a wealthier demographic, but instead for the whole public who can commute more conveniently than before. SNCF had coupled this policy with a major publicity campaign outlining its advantages over the existing modes and to increase ridership. The implementation of these policies, which would only be possible at the birth phase of the mode, was a great success and was publicly received well for the increased practicality of travelling intercity.

Growth of TGV
TGV has been developed and still currently operated by SNCF, which is a national state-owned company. This had benefited the growth of TGV because without the subsidies from the French government, the ticket prices would likely have become higher and may not have expanded the network to regions in France that are less profitable. With the subsidies, the mode was more financially accessible to the public and its continued expansion into various regions over the years have contributed to the increased ridership of TGV.

TGV has faced and is continuing to face the problem regarding the financial viability of running multiple lines. The policy mentioned in the above section was effective in the growing phase of TGV, which was the stagnated development of the high-speed rail network integrating existing infrastructures and developing new tracks along the contours and minimising earthworks. This conservative approach had encouraged new travel mode development with financial stability unlike the counterparts in Japanese Shinkansen, who were faced with financial troubles from the opening due to the development of its exclusive infrastructures.

Policy change had begun from the mid 1990s, when the European Union forced to split the state ownership of rail to their train operation. This prompted the creation of Reseau Ferre de France (RFF) by France as they split with SNCF. While SNCF still maintained ownership of TGV as well as various other rail infrastructures in France, RFF solely managed the operation of rail.

The “All TGV” policy, which encourages the development of new TGV lines and connects all regions of France to the network, has seen financial problems, as some lines connecting to more unpopulated areas were unable to attract enough passengers compared to the high cost of running high-speed rail infrastructures. As TGV is state-owned, it managed to control the price of the tickets to an extent and maintain regular timetables and the routes itself for the less popular routes. This had contributed to the growth of the network and increase in ridership during early and mid stages of the mode, however, SNCF’s debt reached 47 billion euros in 2018.

TGV undergoes network expansion and improvements
TGV underwent steady increase in the train network and infrastructure upgrades over the course of its operation. The cumulative distance of tracks increased from 275 km to 2696 km in 2023. In the growth phase, the network expansion focused on connecting Paris to various populated intercities. After Phase 2 of TGV Sub Est which connected Paris and Lyon was completed in 1983, TGV Atlantique was launched in 1989 which linked Paris to LeMans and later to Tours in 1990. Atlantique had minor improvements from the previous fleet, including improved aerodynamics, braking performance and higher power-to-weight ratio by altering the set.

Domestic rail network expansion continued, primarily linking Paris to other major cities such as Marseille as well as to provide ease of access to the capital city from more regional areas of France such as Rennes, Bordeaux and Nancy. Some of the connection to other regional cities such as Strasbourg and Montpellier served to connect the line internationally in the future.

SNCF began its international expansion 1993, when the route from Paris to Calais was launched. Calais is a port city in Northern France and the primary purpose of this route was to enable rail travel from mainland UK to France via Channel Tunnel, which was an underground rail tunnel built across the English Channel.

This signified the start of attracting different markets to TGV, which were the market who desired to travel high-speed internationally in proximity to France. TGV continued its expansion towards international borders to connect the respective countries’ rail network to its own, including LGV Nord in 1993 which bypassed Lille which would later be connected towards Brussel in 1997, LGV Est to Strasbourg to connect to Luxembourg and Germany, LGV Rhin-Rhone towards Mulhouse in 2011 to link with Basel as well as lines to the Spanish border in 2010. There are multiple other rail networks planned to expand in the future to various regions of Italy and Spain. This highlights SNCF’s efforts to continuously draw new markets to offer an alternative mode to travel internationally to and from France.

During the course of network expansion of TGV, the trains itself also underwent physical upgrades to improve its aerodynamics and power-to-weight ratio to further reduce its energy consumption. After the development of TGV Atlantique, SNCF had launched TGV Reseau in 1992 which increased top speed from 300 km to 320 km, TGV Duplex in 1994 which increased the seating capacity from 377 to 508, TGV POS in 2005 which saw increase in power from 8800 kW to 9280 kW since the TGV’s opening in 1981. Euroduplex was built in 2011 which saw an increase in both power and seating capacity. All the rolling stocks have seen an increase in power-to-weight ratio with each development.

TGV enters mature phase
TGV began to enter its mature phase in 2010 following the 2007-2008 Global Financial Crisis. The ridership which was increasing annually had come to a standstill and this trend has been maintained until today despite the constant development of new lines connecting both domestic and international cities. The passenger-km of TGV had also stagnated since 2010 as seen in figure 1. The small increase in 2017 was due to the opening of TGV Bretagne-Pays de la Loire that links Le Mans to Rennes and LGV Sud Europe Atlantique that links Tours to Bordeaux. Even after this launch, the passenger-km continued its stagnated trend, until COVID19 had significantly impacted the ridership in 2020. Hence, it is safe to deduce that TGV had reached near full saturation from 2010 onwards, however the ridership has not necessarily declined, but maintained.

Future of TGV
High-speed rail in France is increasingly becoming difficult to operate financially, failing to attract substantial increase in passengers after the continued opening of new lines. Various sources suggest different reasons for this decline and their respective possible changes that could be made with the current system. This includes constant development of new lines into the relatively rural areas of France without a proper business despite the increasing strain on the maintenance and operation of TGV and suggests a halt on the development of new tracks (Barrow, 2015).

Another opinion proposes to implement additional stops into the existing routes to expand the market to commuters who travel in between smaller cities and increase ridership (Levy, 2020). This argument puts the Shinkansen into comparison, suggesting that there are multiple travel options in between Tokyo to Osaka, which bypasses Kyoto and Nagoya instead of a direct route which is more common in the TGV network. Currently most of the TGV routes branch out from Paris.

Both opinions however agree on the necessity for a better mode connection when commuting through TGV, especially in relatively more rural regions. With better integration of systems between TGV and regional rail services (TER), SNCF may be able to maintain ease of public high-speed transport in regional areas while reducing the high cost of maintenance and operation of high-speed rail infrastructures.

Despite financial struggles, TGV remains a crucial high-speed intercity service in France. The impact of COVID-19 has brought uncertainty to its future, with the increasing trend of online business meetings reducing the need for intercity travel. However, there is still potential for a return to normalcy in the future. TGV M, a new model announced in May 2021, offers ergonomic benefits, increased seating capacity to 740 from 600, and 20% reduced energy consumption through improved aerodynamics. These innovations demonstrate a commitment to enhancing Europe's train network.

Modelling S-Curve
The mode’s life cycle can be approximated using data visualisation and modelling via S-Curve. Passenger kilometres will be used as a status measure to determine its birthing, growth and maturity. The data used to generate the S-Curve is provided by SDES Traffic Accounts 2017 published by SNCF (from 1990 to 2017) and Statista (from 2010 to 2019). The raw data used is in Appendix 2 and Appendix 3, where the highlighted row is the values used for modelling. The consistency between the two data is validated as the statistics from 2010 to 2017 which they both overlap is equivalent. The data from 1981 to 1989 could not be found, and instead ChatGPT had estimated these values from combining multiple sources. However, these values were not consistent with the published value by SNCF and hence the data from this period will not be used, which is essentially the birthing of the mode.

The modelling is done by using the data to estimate a three-parameter logistic equation which is as follows:

S(t) = K / [1+exp(-b(t-t0)]

Where:
 * S(t) is the status measure in passenger-km
 * t is time in years
 * t0 is the inflection time which in year 1/2K is achieved, given by c/-b
 * K is saturation status level to be estimated
 * b is a coefficient to be estimated

To find the estimation of passenger-km, single variable linear regression was used to estimate the coefficients c and b from the following equation:

Y = bX + c

Where:
 * Y = ln(Passenger km / Smax - Passenger km)
 * X = Year

Various values of maximum saturation K were used to determine the maximum value of R^2 closest to 1. To achieve this, the single variable linear regression was performed for each and every year under various values of K. Then, RSQ function was used in an Excel spreadsheet over the results of every year to find the value of R^2. If this value was closest to 1 out of every K tested, INTERCEPT and SLOPE functions were used to determine the coefficients c and b respectively. These coefficients were then used back in the three-parameter logistics equation to calculate t0 = c/-b and ultimately the predicted passenger-km.

Model and its correlation with the data
The results show that the saturation of passenger-km following the current trend is at 67 million passenger-km, and the time where half saturation is achieved is at the second half of 1999. The estimated model in figure 2 shows close correlations with the data. The model shows the increase in passenger-km at a constant rate until around 2010, when the gradient of the curve begins to decrease as it approaches full saturation. The growth of TGV can be estimated to be between early 90s and late 2000s, which also follows the data. The birth of the mode, which could not be analysed due to the reasons explained above, can be estimated to be between 1981 to early 90s.

Despite these correlations, there are a couple of trends that the model could not accurately portray. The first was the much higher increase of passenger-km between mid 90s and late 2000s and the second was the stagnation from 2009 to 2016. Together combined, the data more accurately showed the start of maturity of the mode. This may partly be due to the increase in passenger-km in 2017 due to the new TGV line opening. Overall, the model does an accurate job of illustrating the general trend and life cycle of TGV.


text: MediaWiki talk:Gadget-markAdmins-data.js

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
User:Sasikrishnasamy

Ayngaran Foundation is a spiritual non profit organization founded by spiritual guru Sasi Krishnasamy

Sasi Krishnasamy is a well-known spiritual guru Social Activist and the Founder of the Ayngaran Foundation in Palani, Dindigul District in the Indian State of Tamil Nadu. Early Life and Education: On January 22nd, 1984, Sasi Krishnasamy was born to Mr. Krishnasamy and Mrs. Nageshwari in the Palani village, and at the age of 5, they moved to Coimbatore City. Sasi Krishnasamy completed his schooling and higher studies in Coimbatore. Professional Life: After completing his education, he worked for a private firm using his skills, and in 2011, he began working in the jewellery industry. Personal Life: As far as God’s gifts go, He was blessed with a wonderful and gorgeous life partner Mrs. Gokila sasikrishna in September 2009, as well as a daughter and son named Sowmiya Sasikrishna and Gowtham Sasikrishna. About the Founder: As a child, he helped people through social services, blood donations, and food donations. He worked with many trusts, foundations, and social service trusts, among others. In 2020, after a long and bumpy journey, he was finally able to fulfill his dream of starting his own foundation. He formed the Ayngaran Foundation in accordance with the Foundation Registration Act. Together, along with his partner, Mr. Sasi Krishnasamy, and Mr. Vince Thomas, formed a team of individuals having the same passion and put Ayngaran on the path to becoming a well-known NGO in India.

title: User:Sasikrishnasamy


text:
Talk:HTML 5 Programming and Web development

This Is Amazing
Thank you for teaching me about HTML now i can actually know HyperText Markup Language to make a website on scratch and code on github TheFloridianChemist (discuss • contribs) 14:04, 15 March 2023 (UTC)


text:
The Pollen Programming Language

Table of Contents

 * About this book
 * Introduction
 * Operating system development in modern languages

The C Programming Language
The major source of security vulnerabilities is pointers.

 * Without pointers, there is no null dereference.
 * Without pointers, there is no pointer arithmetic.
 * Without pointer arithmetic, there is no array out of bounds.

Traditionally, C source is divided into .c and .h. The C source contain no pointers. The header files contain macros that use pointers.

Headers can be used to define typedefs for the .c files to use. Similarly to variable declarations, the new identifier is on the right hand side of the typedef. The following declares a pointer to a my_struct record as my_struct_t. Traditionally, _t means "type" and is used to defferentiate the type identifiers from variable and parameter identifiers.

The amp symbol as well as the asterisk symbols are forbidden on source files.

Allocate new objects on the heap using memory pools. A good implementation of memory pools is provided by the Apache APR library. The API may be taken as a reference of how to implement memory pools.

Object orientation
The concept of object orientation that was developed for the C++ programming language is also available for the C programming language. That can be done by using macros for getters and setters.

Getters and setters check for null dereferences before they are used on an expression. The GLib runtime libraries from the GNOME project is written in C and uses this strategy to avoid memory errors. Keeping that library secure is essential because the GLib runtime libraries are used on all GNOME projects. An example of object orientation in C using macro follows:

In the above code, the comma after the call to the abort function allows for returning NULL as the result of the sub-expression (abort, NULL) to the parent expression which is ...? ... : .... The abort function returns void.

Functions that make use of unknown types should also use macros for performing casts.

Virtual address spaces
Virtual addressing can be used in addition to secure programming languages. That allows the developer to include legacy code written in older programming languages.

Only the root user can run programs which will run as a different user (except for setuid). Daemons can fork its process in order to have a process running under an unprivileged user in order to insulate each API request from each other.

Therefore the only major concern is the part of the programs that parse the request input (such as JSON or XML) which contain the authentication data of the request and the socket connection itself. The part of the server that deals with such type of data should be handled by a carefully verified framework written in a secure language, and the parts which contain code written in an older programming language should be in worker processes which are forked or executed.

The Ada Programming Language
Ada is a programming language focused on memory safety and also in overall program correctness. There is the SPARK subset (not the obsolete SPARC architecture) which proves mathematically that a given program has no flaws.

The Ariane rocket made by the American government was written in Ada/SPARK exploded due to a software flaw. This issue aways comes up when discussing the validity of Ada as a very safe language, but in fact the software flaw was present because a pragma was used. The actual source code snippet containing the section of the rocket that caused the explosion is available to the public by Nasa and can be found online still in these days, way in the future after the explosion was in the news. Maybe it is still a tabu because it is the only aledged "proof" that Ada actually has flaws.

As I mentioned, it was caused by the incorrect use of a pragma that makes false asumptions of the hardware system of the rocked because it was ported from a previous rocket with a completely different hardware.

Besides, pragmas in Ada are compiler specific and are not part of the language. The language does not give the same security guarantees about pragmas because, as I stated before, most pragmas are not defined on the standard. The Ada standard specifications define the keyword "pragma" but they say they are compiler-specific custom code.

According to the Ada standard, the 0xFFFE and 0xFFFF byte sequences are not allowed on strings. Invalid strings are fixed by the Ada runtime. That restriction brings error with UTF-8.

A character whose relative code position in its plane is 16#FFFE# or 16#FFFF# is not allowed anywhere in the text of a program.

Those byte sequences are used in UTF-8 to represent emojis.

Programs written in Ada usually need an aditional runtime with its own types and functions. That runtime may have a part written in Ada (a binding) and a lower level part written in another language such as C.

That is exactly where Pollen comes into play. Pollen can be used as a runtime for Ada for accessing modern operating system features, external libraries or other functionality that is not covered by the Ada runtime.

Here are some good examples of functionality not covered by the Ada runtime:

 * UTF-8;
 * Memory streams;
 * Database support;
 * Modern compression algorithms;
 * Modern cryptography algorithms;
 * Networking (Berkeley sockets).

Pollen brings all those features to Ada if used as a runtime.

Freestanding Ada code
Creating freestanding Ada code for being used as an operating system or as the main code on a microcontroller is considerably more complicated than creating freestanding code in C.

Creating freestanding Ada code is more difficult because Ada requires a runtime to compile and to run. But the important part to understand is that the Pollen should follow the example of having all the runtime code required for a language to run on bare metal as freestanding code is that everything about the runtime must be covered on the standard and publicly available documentation so that kernel developers can effectively use the language.

The Ada runtime is written in Ada itself and calls C code using the pragma Import directive to run code that depend on unsafe features not provided by the language, such as:

 * pointers and pointer arithmetic;
 * exception handling;
 * tasking;
 * delays;
 * array bounds checking;
 * and others.

Those are all portable across compilers, operating systems and hardware. The hardware on which the Ada code runs do not necessarely have to provide all of those features therefore not every feature must be present on a specific hardware or operating system. All of those features are defined on the Ada language specification standard.

Ada code typically relies on code generated by the compiler such as those for null checks on pointer dereferences. However those operators - such as the dereference operator in this instance - can be overriden manually.

Those automatically generated code do not generally pose danger to a low level developer as they call the exception handler on the Ada.Exceptions package. If a programmer wants to support null checks on pointer dereferences and comparason operators, all that is needed is to create the appropriate handlers on that package on the Ada runtime of the kernel of the operating system that is being created.

Integer overflow checking
Overflow checking is done by the Ada runtime by using operator overloading as in object oriented code.

The Ada language provide no types. They are all defined by the runtime and the overflow checking is usually specified as a compiler intrinsic with:

Global allocator
The global allocator made by the the definition of the Root_Storage_Pool type and its methods, also as in object oriented code.

Calling Ada code from C
Create your Ada source files, and compile them to object files using the GNAT compiler, gcc. For example, let's assume you have two Ada source files named mypackage.ads and mypackage.adb, and you want to compile them to object files:

Create a C source file that will call the Ada library function(s). In this example, let's assume you want to call a function named my_ada_function that is defined in mypackage.ads. The C source file might look like this:

Create a C header file (mypackage.h) that declares the Ada function(s) you want to call. In this example, the header file might look like this:

Use the GNAT compiler to generate C bindings for your Ada package:

Use the C compiler to compile the C source file and link it with the Ada library file and the C bindings file:

The Ada standard library handles Unicode using wide characters. The package Interfaces.C.Strings does not support UTF-8 or wide character encoding. It is wise to include character transcoding functions on the C side instead of the Ada side. Those functions should convert Unicode strings to Ada Wide_String and similars.

= JIT =

 * GNU libjit (libgccjit-10-dev)
 * LLVM bytecode

Kaleidoscope is an example of a JIT language that uses the LLVM code generation.

LLVM code generation
llvm-config is similar to pkg-config but it is specific to LLVM code generation. llvm-config must be found in $PATH for it to work. It is expected to be only one llvm toolchain associated with that llvm-config. That toolchain is responsible for code generation and may have different architectures as targets.

Steps for producing bitcode with llvm-dev:

 * Create a new Pollen plug-in
 * Add CFLAGS and LDFLAGS llvm-config
 * Create module;
 * Add code;
 * Add basic blocks;
 * Append basic block to program in memory;
 * Write bitcode to object file or BC file on HDD or SSD.

Contributing
Contributions to the Pollen project are welcome.

You may crate a bash script to automatically insert your Git username and password. Push code to a Git repository using simple HTTP authentication.

Hosting
Pollen requires running native code, so a typical PHP hosting server will not work. Free CGI, Docker and VPS hosting are difficult to find as of March 2023.

Google offers free hosting suitable for personal use on their Cloud Run.

Pollen
The libpollen runtime has a function called hello world. This function is supposed to be called from the tmpl script file. The libpollen runtime is optional and is not required for a program written in Pollen to run.

The compiler and the interpreter get the symbol for the "hello_world" function in different ways.

The interpreter gets the symbol using dlopen on the runtime library selected by the script. The select script is the "lib" atrribute on the "pollen" element.

The compiler gets the symbol by using the linker as the object file created created from the script is linked against libpollen.

Authors

 * Mateus de Lima Oliveira

External link

 * Pollen official page

title: The Pollen Programming Language


text: Talk:FHSST Physics/Electricity/How Voltage, Current, and Resistance Relate